Jump to content

D. Ackermann

Members
  • Posts

    13
  • Joined

  • Last visited

Everything posted by D. Ackermann

  1. Ok. Now I have my hands on it. I have a cRIO-9047, which should be quite fast. To get my test to work fast, I had to strip down the current project a lot. I kicked out EtherCAT master, Softmotion, PID control and logging, which was all programmed in actors. With this reduced code on my PC it takes about 3 minutes to have the program running after I hit start in LabVIEW. I then put most libs of this project in a wrapper lib and turned this into a packed project lib. This reduced the deploy time to about 1,5 minutes. I noticed then, that I see a lot of toolkits VIs in the deploy process window. JKI this, OGTK that.. So probably using a lot of Toolkits on RT is not really optimal.. I think it will require a redesign with project packed libraries, while also checking which toolkits are really necessary, to be able to work efficiently in this project
  2. I have to say, I did not work on it myself yet. I will receive a cRIO tomorrow to start to work on this problem. I just wanted to start to collect information beforehand on what can be done to reduce the time. I will post more details then. Thanks!
  3. Hi I am currently involved in a project with a test sequencer based on actor framework executed on cRIO platform. One major problem that arose, is very long deploy times for the code to the cRIO. Meaning the start LabVIEW code in debug mode. It takes up to 8 minutes to get the code started. I want to create a strategy on how to optmize the project to reduce the deploy times. And would be glad to receive some work experiances from the field. We use LV2020. LVOOP is heavily used. We do not use precompiled libraries yet. We heard from another company, that they had problems using it with actor framework, but cannot say what exactly was the problem. Are there any? Thank you in advance. Dermot
  4. I will take a look at VI Scripting then. The situation is like this: LibA is out there for years. Now a 2.0 version of LibA called LibB will be created. LibB is doing things quite different internally and depending on other software. Therefore the transition from LibA to LibB requires multiple changes on the systems it is deployed to. A developer with multiple deployed systems will have a transition period where he has to work with LibA and LibB. That is why I don't want to make it LibA 2.0. That would require installing the LibA versions back and forth. With creating LibB they can be installed parallel. Now I am trying to find the best way to upgrade projects from LibA to LibB..
  5. Unfortunately, the libraries are locked with password. Also the libraries are distributed to other users and the way to replace them should not be to complicated. I never looked into VI scripting. Maybe this could be a way to replace all lvlib VIs in a complete project?
  6. Ok, I just found out, that if I add an additional step of pointing the CLFN to the dll again in LV 2013 and saving the project. Opening the project in LV 2019 from a different location works for LV 32 and 64 bit. So I guess the problem is somehow conencted to saving the project for previous version. I can live with this..
  7. Yes, I thought about both options before. Both don't really work for me. If I use "Specify path on diagram" checkbox, the dll is not automatically put in the data folder when building an exe. And it is actually not one dll. It is multiple dlls from another company. The dlls have linkage between them. So I cannot change the naming. Thanks.
  8. Hi I am looking for an efficient solution to create a VI library for LV 32 and 64bit, that uses a dll. I spent about a day now without success.. I am cretating the library with LV 2019 and saving it for LV 2013 to have it available for older LV versions. The dll has the same name in 32 and 64 bit version. I am using the conditional disable structure to detect if it is LV 32 or 64 bit in the code. In the structure are 2 call library function nodes. One for 32 and 64 bit version of the dll. The dll is in a subfolder of the VIs. The VIs are organized in a lvlib. I also added the dll to the lvlib. So all the information is there.. - First I configure the call library function node in LV 32 bit. - Then I save all and close LV. - Replace the dll in the folder with the 64 bit version. - Then open LV 64 bit and configure the second CLFN - Save all - Then save the whole LV project for LV 2013. - Then change the path to my current LV project. Otherwise LV 2013 would just use dll from my LV2019 project. - Go to the location of the LV 2013 project. Raplace the dll with the 32 bit version - Then open LV 2013 project in LV 32 bit. - Open a VI that calls the dll and get the search dialog saying it cannot find the dll - When looking into the CLFN, I see the the absolute path to the dll in my LV 2019 project is saved in the path field. I tried using a relative path in the CLFN path field, but it always replaces it with the absolute path. Just setting the dll name is not an option, because I need that the dll is automatically put in the data folder when building an exe. I think the problem is, that the CLFN nodes are messing with the information put into the path field. If I could enter a relative path, that is not replaced with an absolute path it should work. Did anybody go through the same pain here? I really want to avoid having two VI sets for the library for 32 and 64 bit. Thanks
  9. Hi I am looking for an efficient way to replace the VIs of a lvlib with another lvlib with the same type of VIs in multiple projects. It should be done without having to do the replace for each single VI, because there are up to 50 public VIs in the lvlib. As an example: A lvlib with these VIs: LibA.lvlib:FuncA.vi LibA.lvlib:FuncB.vi LibA.lvlib:FuncC.vi Is to be repleced in all the code with another lvlib with these VIs: LibB.lvlib:FuncA.vi LibB.lvlib:FuncB.vi LibB.lvlib:FuncC.vi Of course the VIs have the same interfaces. In a text based language, this would be quite simple. How can this be done in LabVIEW Thanks
  10. Kurt and Paul, well, the reason I want to cut out the To more specific class conversion is I am creating an API, that uses LabVIEW classes, but it is targeted to the normal LabVIEW user, which might never have used LabVIEW classes. I know I will be in a support hell, if I dont find a way to avoid the to more specific class conversion. If I put it in a collection class, then this class needs to know all existing classes. And if a new class is added, also the collection class has to be updated. This doesnt work for me, because users can also add their own classes. The vehicle, truck, car code was just a simplified code to represent the problem. In my case it is about a modular IO system. So I have an array of ModuleClassBase and inherited Classes ModuleAnalogIn, ModuleAnalogOut etc. I can get the module by index from the array and use an aproriate method like write outputs or read inputs. But coming from the array a to more specific conversion has to be done before passing it into the read or write method. This is going to be too much for a lot of LabVIEW users :-) Cheers
  11. Thank you very much for the replies. The collection is a concept I also use and also think it has many benefits. But here I actually was mor interested in the point of using vehicle class as interface on a truck method. This to be able to not have to do "To mor specific Class) conversion in the places wher truck class is needed. The conversion is done inside. here an image TruckMethod.zip
  12. Hi, I was thinking about a problem, that I experiance often with arrays of different class objects. I have a approach to solve this convenient, but would like to get oppinions, if I am getting drawbacks by this I don't see. So it would be nice, if I could get some feedback on this. Here the problem: Arrays of mixed classes are of type of base class. When extracting an object and appying a method of the inherited class, a to more specific class conversion has to be done before wiring. This is really a pain when to be done a lot of times. I thought now why not use the base clase as interface in the inherited class and do the to more specific class conversion inside. Then wiring is much easier. Please see example. Thanks Dermot ObjectInterfaceProblem.zip
  13. Hello I am working on a DSC project and am having trouble to find a way to programatically change the citadel logging path of a shared variables libraray. The application has to run as an Exe. So using the Project properties won't be a solution I guess. I hope someone can help me on this. Thanks Dermot
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.