Enhanced EPICS Support

[Sokoll]

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!

[lanylg]

Issue1, CAR#209223 is filed.

Issue2, dynamically creating EPICS Server is going to be supported in DSC2010 and RT2010, and we plan to support creating EPICS Client dynamically in future release.

Message Edited by lanylg on 02-19-2010 08:02 PM

[Sokoll]

Issue1: The link is not available. 

http://nippm.natinst.com/itg/web/knta/crt/RequestDetail.jsp?REQUEST_ID=209223

Is there a way to get the information? 

[pheest]

I would like to add comment to Issue 1.

While it is possible to import a .db file, all records are imported as seperate LabVIEW items.

Each PV has to be seperately added as a 'bound shared variable' for inclusion into a VI.

Then each PV will need to be seperately connected up to a control or indicator, unless some means of iterating over the collection is implemented.

This is fine if there are 3 or 4 PVs (as is the case for the example app).

My current application is quite modest in scope - there are 15 PVs for each of 6 devices, so 90 PVs altogether. It is barely feasible to follow this manual process for each of these - it would take hours and be very finger-trouble prone.

Many EPICS IOCs can use thousands, or millions, of PVs.

I would suggest that the .db file import wizard process the PVs from each file into a cluster.

Or - possibly better - process PVs into an array of clusters.

IMO, the current implementation just isn't scalable to 'real world' control system IOC use.

If NI wish to provide LV integration with large-scale EPICS projects, I beleieve a better way of doing needs to be found.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.