LabVIEW Idea Exchange

I suggest that the LabVIEW application builder should include an option to rename shared variable libraries (i.e., add an index to the existing name) when building an application.  This is necessary for replicating an application.

For instance, for a component we developed we host shared variables on MyComputer (so that we can use DSC functionalities).  Applications on MyComputer (the view) and on a cRIO (the controller) read and write the shared variable values.

Now we want to clone these applications so that we can run multiple instances of them.  In particular, there will now be six instances of the cRIO application, each deployed on a separate cRIO; there will be six instances of the MyComputer application as well, but these will all run on the same PC.  Currently we anticipate (we have not done this yet) that we will be able to create six build files, each pointing to a separate aliases files, in order to handle the fact that the cRIOs will have unique IP addresses.  On the other hand, there is no way to handle building unique shared variable libraries in the application builder.  At the moment we can edit the project manually by changing the library name (e.g., add ‘A’ to the prototype name), then building the application, and repeating the process six times.  This is not especially difficult, but it is not a good long-term solution, since any change will require someone to repeat this process (and more importantly, know that they must do this!).  I suggest this functionality should be part of the build specification itself.

Epics Support in LabVIEW 2009 DSC Module has increased usability of LabVIEW in EPICS environment very much! But:

1. Import of database file is not really working!

When creating Epics client IO Server there is this nice feature to <Import> records from database file.

But when doing this there is only on field "VAL" per record created. All the other fields must be added manually though they are defined in the db file.

So please let the import routine pay attention to all the fields that are defined for each record by default and perhaps make it selectable.

This little change shouldn't be a big issue I guess. And it would increase the usability a lot!

2. With DSC it is possible to create on runtime only server types Modbus/Modbus Slave/OPC Client.

Please add Epics Server & Client here.

The goal is to be able DURING RUNTIME to first create sets of Env.Vaiables dynamically (already working with DSC) and then create the network publishing EPICS server.  

And of course the other way round: Please let me be able to create an EPICS client by importing a db (dbd) file dynamically and then bind it to dynamically created set of env. variables.

From what I heard from many of our synchrotron customers LabVIEW still has not arrived in this (huge!) EPICS community. 

I think it is on a good way with LV 2009 DSC Module. Please let it keep on going!

Currently the synchronous and asynchronous modes of writing data have little to no effect when communication over TCP. The write will return immediately after buffering the data to be written. However, the data it self may take considerable time to actually be written to the network. Absent some type of hand shaking at the application level there is no way for an application to wait until all the data has actually been written. The native LabVIEW TCP Write behaves in the same manner as the VISA write. Given this behavior it is impossible to implement a well behaved write queue for queuing up and transmitting data to a device. For example a normal print queue will open a connection and send the data to the printer. It will not attempt to open a second connection for the next print job until the first one has consumed all of the data. If a large amount of data is being written it can take time for all of it to be transmitted. The way the VISA or TCP write VIs behave the print queue would open a connection and write the data. However the call to the write would return immediately because the lower level network stack has accepted the data and buffered it. The print queue then believes the first job is complete and begins processing the second job. This will mean that a second connection will be opened. Some devices will allow multiple connections and some do not. However without the ability to actually wait for the data to be completely written the queue would have to continually try to open connections. This would be unnecessary network traffic and and unnecessary communication with the printer.

I would like to see an open on the write VIs to allow for a true blocking write. The write will not return until the data has truly been transmitted. The current behavior is also valid and can be retained.

Note: I have not tested the behavior on other types of interfaces so I am not sure if this is a TCP only issue.

Hello old friends,  it has been a while!

I would like to see MQTT client functionality added to LabVIEW.