EIONode - a problem when getting data type of a newly created one

[Jerzy Tarasiuk]

Hello. I use LabVIEW Scripting to create an EIONode (a connection to I/O defined in my project) in a VI for FPGA.

Then I get the EIONode terminals and examine its properties, and when I am adding a connection to one I/O, the data type of the terminal that is returned is 'void'; when I am adding connection to another I/O (it may be the same), the terminal for the first connection has correct data type. In the VI (when examined from LabVIEW designer) the terminal has the correct data type even when I create one connection only. Am I missing something in my program?

I also tried specifying State for EIOPlaceDownEIONode.vi (place eio node on BD), it made an extra slot for the EIONode, but I failed to pass I/O specification via the State cluster in a way to get the connection.

The main VI BD is in make_eio.pdf (two different versions of the main VI are vis4t3d.vi and vis4t3d_st.vi); the State is prepared by mk_eio_st.vi (mk_eio_st.pdf); the main VI uses get_aptarg.vi (get_aptarg.pdf).

The main VI execution order is nearly along error wire: get FPGA Target context, create FPGA VI, get its BD reference,select the EIONode as an GObject (i.e. its Selected property is set - it is later used to identify this EIONode), add a channel and close, traverse the VI for GOBjects, select the last EIONode (here ClassName and Selected are examined, must be "EOINode" and TRUE for the GObject to be passed), cast the GObject class to XNode, traverse the XNode for terminals, get the first one and show its properties, save and close the FPGA VI.

The code always gets the last EIONode (there is one only, anyway) and shows properties of its first terminal.

Note: a single I/O connection adds six terminals to the EIONode - first, except the data terminal are two terminals for FPGA I/O name (input and output); next, each of these has two terminals - I guess one is for BD connection, and another one is for I/O connection. The traverse finds the data terminal first, then I/O name terminals, for all connections, but for one "side" (its owner has "EIONode" class); then the traverse finds terminals for the other side, usually in other order.

The LabVIEW version I use is 18.0.1f4 (32-bit).

I would like to be able to get data type of the newly created EIONode even when it is connected to one I/O only.

What should I do for the data type to be available?

make_eio.pdf get_aptarg.pdf mk_eio_st.pdf get_aptarg.vi mk_eio_st.vi vis4t3d.vi vis4t3d_st.vi

[ensegre]

When I tooled with programmatic generation of EIOnodes (not that this makes me an expert of them, nor that I remember too much of my trials and errors of then), I got the impression that the little set of EIO scripting VIs is all but complete and bug free, less to say documented. To understand the state cluster was way too esoteric for me, and I wasn't able to use AddChannel. In the end I achieved what I wanted by using ModifyChannels and SpecifyEIONode. Even with that the result was not yet sane, and cherry on the cream, the trick to fix up things automagically was to cut all I created and repaste it on the BD. Meaning to me, that to complete the operation the necessary methods are not exposed in the undocumented set given, but luckily some internal sanity cleanup is enforced when dropping clipboard contents.

Maybe my task was easier, because I knew a priori the type of the terminal I wanted to connect to (i.e. U8 or int16 or boolean, determined by the name itself), so I only had to wire a control or an indicator of the right type to the node I created, and not to find out that type.

[Rolf Kalbermatter]

AFAIK, documentation about this part of LabVIEW is only available as part of the cRIO C module development toolkit. And you had to sign a special agreement to get that. The part number is 779020-03 and it costs currently € 6200 and has a delivery time of 85 days according to the NI order system, but it has no product page anymore and it is questionable that you can find anyone at NI who even knows what an MDK agreement is. AFAIK it included also an NDA section.

The whole Elemental IO was developed for cRIO module drivers but its functionality was never really finished.

Edited December 19, 2023 by Rolf Kalbermatter

[Jerzy Tarasiuk]

Hello, I discovered a solution just today evening (around 20 of local time, now here is 22:28).

Use EIOPlaceDownEIONode.vi to make an empty EIO Node; then use EIONode_ScriptAddChannel.vi to add channel(s); if there is one channel only, use also EIONode_ScriptModifyChannel.vi to set the channel - after the Add the terminal has Void data type, the Modify causes it to get the correct data type.

When more than one channel is Add-ed, the Modify is unnecessary - the data type is set correctly for all channels.

I hasn't investigate this in detail: seems "direction" can be specified as "none" unless more than one direction is valid (as for e.g. Digital Out signals); and possibly using Add (without specifying channel parameters) to add as many channels as needed, then Modify to set their parameters can be used, too.

I attempted to find a way to delete a channel from EIO Node (by "Delete" Invoke Node on a terminal), no success.