Jump to content

Mads

Members
  • Posts

    437
  • Joined

  • Last visited

  • Days Won

    27

Posts posted by Mads

  1. Here is a good thread that covers various related scenarios:

    https://forums.ni.com/t5/LabVIEW/why-open-new-clone/td-p/2976973

    Regarding the queue; if it is not in use anywhere (regular dequeue e.g.) so that the close can be detected there? If it is polled in the timeout you probably do not need to run that timeout every 10ms as that will put a high load on the CPU. For users to perceive things as "real-time"/instant anything below 300 ms or so will do.  You can also wire the error wire directly to the stop terminal unless you have other cases there that generate a boolean, then using the status alone is more practical..

  2. Not having looked at the details of the code you have, here is a quick general comment:

    If the dynamically called error monitor needs to close if the main VI closes I would not code that by having it monitor the boolean of the main (reading values using property nodes is not optimal in any case, globally or locally), but rather destroy the queue in main when it closes and then have the dynamic VI react to the queue erroring out, or use a dedicated user event, notifier or channel wire to message this (bidirectionally if needed).

    (There are countless ways to do this, all with their pros and cons. A named "System" notifier e.g. that is used for any part of the application that needs to know when to gracefully shut down, reload setting etc. is *one* simple solution that allows anyone to monitor it without polling or having anything pre-wired (just mentioning one such solution here is opening up for a bunch of protests from people preferring other methods due to cons with this particular method, but anyway...))

  3. 1 hour ago, Jerzy Tarasiuk said:

    Hello. I want to create a VI for each serial port that will configure the port according to configuration data sent to the VI - this requires many connections inside the VI and results in many possibilities of mistakes in these connections if they are to be done manually. I would like to avoid these mistakes. Currently, I can use Scripting to create Method Nodes and Property Nodes needed, then request setting the serial port in them manually, then  use Scripting to create connections, and finally report all connections to a text file for verification. But I neither know how to set the serial port in these nodes using Scripting, nor I know how to get these settings for verification.

    BTW: is it possible that two Property Nodes for a serial port look identically (have the same port in their header lines, the same elements, data types for these elements are shown by the same colors...), but have different functionality (e.g. something hidden was created in one of these nodes while editing it)?

    Any code can contain errors. If you script the code you are just adding another layer where you can have errors (the script itself, in addition to the code it generates). When the script has created the code you still have to test the generated code to see if it works correctly. If you write it manually and test it (easier than testing scripts as you can test its intermediate steps directly as you progress) you can use that code for all ports, not just for one.

    Having to repeatedly create complex but similar code from scratch could justify doing it with scripting to reduce the risk of human errors, but here you can still handle it by having the code cover all scenarios and/or with code reuse . And much of the code has been written and tested for you already (examples) so all you need to do is add whatever extra functionality you need and test those changes.

    Have you tried solving this the easy way by relying on the RT OS and VISA support already, but observed that it does not meet the your reliability requirements? Or have you just assumed that it will not and are optimizing it prematurely, making the path to a working solution unnecessarily hard and complex? 

  4. The top one, the SAC, will run even if the root loop is busy, AND allows you to set the inputs. This function was not available in LabVIEW until version 2011 or so. It is especially useful if you need your application to spawn VI clones to handle various events (TCP session handlers for example) regardless of what the user is doing in the GUI...

    The two bottom ones will be blocked if the root loop is busy, e.g. if the user happens to be viewing the time picker of a time control it will halt until the user closes the time picker.

    Before the SAC was introduced in LabVIEW you had to use the run method (bottom one) if you wanted to avoid having to wait for the dynamically launched VI to complete (it has the Wait until done input). The Call by reference node on the other hand had the advantage over the run method of offering control inputs to the call whereas the run method would require you to use set control invoke nodes for that. 

    Here is a long thread about the root loop issue from before the SAC was introduced:

    https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idi-p/1417794?search-action-id=359039184054&search-result-uid=1417794

     

    • Thanks 1
  5. 8 hours ago, Jerzy Tarasiuk said:

    Hello. My aim is to access these ports directly from FPGA program, without VISA and drivers that are in RT part. It is possible when the program is edited manually in LabVIEW development environment.

    And to do that you can use the examples you find if you search for 987 in LabVIEW examples. But you are for some reason also trying to script the creation of such code, is that an additional requirement or could you just edit the examples and compile it into your bitfile?

  6. On 2/28/2024 at 12:33 AM, Jerzy Tarasiuk said:

    Are you sure? I initially supposed NI-9871 serial ports are accessed via the RT OS, but I was pointed that I was wrong - they are connected to FPGA and the RT OS accessed them via FPGA. Seems to be sure I need a test: write a LabVIEW FPGA program that will send data via a serial port, start the FPGA program and reboot the RT OS (it is configured to allow the FPGA program to continue), monitoring the serial port data on a PC host: if the serial port is accessed via the RT OS, the data will be disturbed. I hope these serial ports are connected directly to FPGA - it is important for safety of the system.

    In LabVIEW FPGA NI-9871 serial ports are accessed using Property and Method nodes (there are several properties and 3 methods - Read Byte, Write Byte, Clear Rx FIFO); I/O Node cannot be used for them.

    Seems that two serial ports on cRIO itself (not on a C-Module) can be accessed from RT OS only, as well as serial ports connected via USB ports.

    The 987x modules *can* be accessed just like any other in-built serial port (using the VISA serial functions) as long as you have installed the 987x support package on the cRIO (option that should be available in the list when you choose to install the system image etc on it). No need to even think about their connection to the FPGA then. Now, before that support package was available you did need to add FPGA code, but even then that code is available as an example so you do not need to figure much out anymore...We used the FPGA-method 15 years back or so, now we just install the support package and use it with VISA.

  7. We do not have anything identical, but I do relate. The rate of critical bugs on cRIO seem to have risen. We currently have cRIO-9030 and 9041 devices that run fine for anything from 1 day to 3 weeks and then kills an application that we had no issues with prior to moving from 2018 to 2020. No worrying memory-, CPU- or disk usage up front - and nothing in the error logs. Tedious troubleshooting. There was a recall of some 9030s not so long ago too due to faulty components. On some there are even issues with the BIOS (>50% CPU usage when idle anyone...?). The known issues lists contain quite a few serious bugs too.

    Simplifying the RT application until the issue goes away is a tredious enough strategy. Add all the recent BIOS, OS, LabVIEW and driver issues and you are in a world of fun...

    Here is a similar scenario from 6 years ago: 

     

  8. 39 minutes ago, Rolf Kalbermatter said:

    Thanks guys for actually checking out the OpenG ZIP library.

    Yes there is no Realtime support yet in 5.0. I was already struggling with normal Linux support quite enough, so did not want to add yet another challenge. There will almost certainly be no support for Pharlap and VxWorks in 5.0, unless someone is really begging very nicely for it. 😁

    As to the Linux installation problems, I'm sorry about that. I did move to LabVIEW 8.6 for testing and building, since that is the Linux installation that I have available, but apparently forgot that I had patched the LabVIEW 7.0 OpenG Builder to not bork the shared library names when building a distribution for a package.  So I have to investigate that. Also there is still an issue with support for Unicode ZIP archives, but since that is not happening to often it should not be a serious issue for the moment. But I'm investigating the proper fixes for that. I just hope that the NI Linux RT installations offer a similar support for dealing with Unicode as do normal Linux distributions, otherwise things will get nasty.

    Ah. Linux RT support is the big thing for us . We used ot have some VxWorks targets, but those are obsolete now. I'll revert back to 4.2b.

  9. The RT Image folder does not seem to be updated with the newly released version 5 of OpenG Zip...How is the process to install it on Linux RT targets now? I looked for an .so file for 5.0 or an option to install it in NI Max, but have not found it yet?

  10. So you do have modbus communication, but the problem is that you *sometime* get a timeout? You are able to read/write data from the device, it just is not stable? If so the serial port seems to be working and all you probably need is to tune the timeout parameter or troubleshoot the device that replies slowly or not at all on some polls...What are the timeout parameters in this driver and their values?

    I would connect a simulator instead to the port (ModSlave32 e.g. if the device is a slave,or ModScan 32 if it acts as a master...You can also run a trial of our Modbus Master that can be downloaded here: https://www.clampon.com/products/software/modbus-test-master/) that will let you view/ debug the communication (how often does it poll, do the poll commands look OK (can be verified in online verification tools e.g.) and does it timeout even if the simulator sent out a reply etc...). Using a simulator tool to verify that the connected device  replies as it should if connected to that is also a good thing to do.

    (If that is not what you meant I would test this without involving Modbus or anything first. You can use a terminal program on the PC you connect to the serial port. We have one written in LabVIEW that simple to use, it can be downloaded here: 

    https://software.clampon.com/ClampOn_Serial_Tool_CurrentVersion.zip

    On the sbRIO you can run one of the serial IO examples that just initializes the port, writes something and reads...then check with the terminal program if you get what you wrote and read whatever you send from the terminal program. Once you have basic serial comms workingyou can go back to the modbus driver and see if that has any issues when the basic functionality is OK. If it does you take it from there..)

    I've never had a need for NI Serial on any of our cRIOs or sbRIOs, only VISA and as you say the support for 9870/71 add-on...Perhaps they just list that driver as needed to cover the case where it is actually used with equipment that requires it? You could try to download the NI Serial driver separately, but normally NI Package Manager should present it as a possible option during software installation from NI Max, especially if you are using a system image.

     

     

  11. NI Serial is not required for the use of serial ports built-into the sbRIO-9627, only VISA. So that is not the problem.

    I would try to simplify this down to a simple VI that initializes the port and tries to read or write to the port. Check if the initialization returns any errors and whether you get any data in or out of it (connect a PC with an RS485 uinetrface to the RS485 port and see). Note that if you are using 2-wire RS485 you will need to set the port in 2-wire mode for it to work...

    (I would also stick to the 2020 RT RIO-install instead of the 2021 system image, but that's an unrelated story... )

  12. Ran into another 2023Q3 issue with Matrix functions as well when buidling another application in the same project, the solution to that has been discussed here already though:

    https://forums.ni.com/t5/LabVIEW/Impossible-to-build-a-working-EXE-in-2023-Q3-if-matrix-functions/td-p/4327930


    I'll test today if any of these issues have been addressed in 2024 Q1...(not discussed in any of the release documents so far as I can see).
     

     

  13. Having mostly completed a major update of one of our largest projects I wanted to evaluate if we should take the step from LabVIEW 2022 Q4 32 bit to LabVIEW 2023 Q3 f2 64 bit before release...Unlike many we seem to rarely experience issues when upgrading (7-2022...), but this time I've hit a wall.

    I had read about how people have problems with buidling applications with VIMs in 2023Q3, but there seems to be all kinds of other issues going on. At first builds would fail with Bad VIs, but clearing the compile cache removed that. Now instead, LabVIEW hangs on "Initializing build", then crashes after a while. I've reinstalled/fixed the full LabVIEW installation, mass compiled everything including the entire VI lib etc...but to no avail.

    I see a lot of users say they have moved back to 2023 Q1, or plan to wait for 2024 (will there even be a new release in 2024 I wonder...), but are there users out there that do get things to work fine, even with RT Linux targets and 64 bit? I'll reinstall once more and this time try the 32 bit version...but if things still do not work I think we'll skip 2023 and hope for better days in 2025(?).

  14. How far from the goal are you now, and have you identified where the time is spent?

    If you e.g. just manually launch the LabVIEW application and flag when it does its first action, how much of the minute is spent already and how much time does the rest of its tasks use? You say you want the program to be launched by Windows as quickly as possible too, how much time does it take for Windows to launch it now compared to any other simple application/service you can set up?

  15. When I first saw the compount add I though that must be use because it is quicker than multiplying by 3, but in the tests on my machine it is the slower. With the replace logic though it does not matter anymore.

    A digression: Branch prediction is an interesting phenomenon when dealing with optimizations. In this particular case it did not come into play, but in other cases there might be a benefit in making consecutive operations identical 🙂 :

    https://stackoverflow.com/questions/289405/effects-of-branch-prediction-on-performance

  16. You beat us well @ShaunR 🙂

    Normally I would use replace in situations like this too, to get the advantage of the preallocated memory. I improved some of the OpenG array functions that exact way (which is now included in Hooovah's version), but lately I've gotten so used to the performance and simplicity of conditional indexing that I did not grab for it here 🤦‍♂️

  17. A bit quicker it seems is to use conditional indexing, like this:

    image.png.59fdb6049072874cd21d0b99112feec5.png

    On my machine I got the following results (turned off debugging to avoid it interfering with test and removed the display of input as I would occationally get memory full errors with it):

    Original: 492 ms

    ensegre original: 95 ms

    ensegre with multiply by 3 instead of 3 adds: 85 ms

    Conditional indexing: 72 ms

    There might be even better ways..The efficiency of conditional indexing is often hard to beat though.

     

    demo_rev1.vi

  18. On a related note GDevCon 4 just ended in Glasgow with a record number of attendees....👍 (Maybe that is partly because the alternatives are not as good/many anymore, but let me be optimistic for a while...) If Emerson does not want to kill or starve LabVIEW, maybe there is a nice future beyond 10 years as well. Retirement age is steadily getting pushed upwards though so personally it would be nice if things went on for another 25 years, or even better; allowed our kids to make a career working with G everywhere in 2050😀

×
×
  • Create New...

Important Information

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