NI-XNET Custom Device for NI VeriStand

[O_Proulx]

Please use this thread for questions and comments on the NI-XNET Custom Device for NI VeriStand.

[DiscoBall]

Page has been updated. New link at: NI-XNET Add-On for NI VeriStand. For future reference you can find other custom devices at the NI VeriStand page and clicking on the
Explore NI VeriStand Add-Ons link near the end of the page.

[h_yong]

Hi, I just posted an XNET custom device question here: http://forums.ni.com/t5/NI-VeriStand/XNET-custom-device-switching-databases/td-p/1173387. Please feel free to delete/move that if you'd like to keep all XNET questions in onen thread. Thanks.

[LaRisa_M]

As the device is written currently, it appears that the XNET messages can only be edited/configured in the database editor. The custom device only references the database as is, so the messages are static once they come into VeriStand.

Is there any way to edit the messages from VeriStand? For example, if I have a cyclic CAN message, can I change its transmit rate during run-time from the VeriStand workspace?

[O_Proulx]

Hello LaRisa,

The custom device currently only supports "reading" the database information from a static database file.  The NI-XNET database editor can be used to modify any database attributes.

If you modify your database, the system explorer will reload the new attributes the next time it loads.  Also, the database is deployed to the RT target everytime a new configuration is deployed, so the changes will be updated on the RT side as well.

The one caveat is that you can't change any of your cluste/frame/signal names!  VeriStand stores these in the custom device (in the .in4 file).  So if you change name "X" to "Y", the next time you load the system explorer, VeriStand will look for "X" and will throw an error because X is no longer there.

As for creating the objects in VeriStand, it would be possible to implement this.  NI-XNET enables you to create an entire database in memory.  You could create attributes for the custom device and store all the information needed in the custom device itself.  You could then read those attributes on the RT engine and create an in memory database using those attributes.  You can look at the CAN Dynamic Database Creation example (HW IO - CAN - NI-XNET - Advanced) for more information.  The source code of the custom device is also available.  Keep in mind that we already have a fully supported database editor that can do all this outside of VeriStand...

I hope that clears things up.

[kevin.key]

Right now the custom device just displays all of the messages in the CAN database, but it would be nice if you could filter through the messages by ECU.

[h_yong]

Hello,

I'd like to know if the custom device as written has a provision to select the software selectable CAN termination from the System Explorer? I thougth I remember seeing this option at one point but cannot find it now. Perhaps I was getting it confused with the XNET bus monitor. Thanks.

[DiscoBall]

HI hyog,

As of NI XNET 1.5 Custom Device the option is not exposed in the System Explorer.

[h_yong]

Hi Discoball,

Thanks for confirming that termination is not selectable from the System Explorer. Can you please indicate to me where I can enable termination in the XNET custom device source code? I am considering adding it into the source code and rebuilding it. Thank you.

[O_Proulx]

Hi Kevin,

That is a great suggestion (filtering by ECU).  The custom device current does not have any filtering options for frames, so it would require a little bit of rework.  Feel free to experiment with the source.

Hyog,

To include the termination option, you will need to add an attribute to the customer that says to enable termination or not.  You can look at the transceiver example in the XNET Main Page VI.  You need to read the attribute on load (to make sure your control has the default value) and then add a case structure that sets the attibute on a value change.

On the RT engine, you need to read the attribute and set the interface property when it is set.  The attributes are usually read in the RTEngineParseCluster.vi in the initliaze case.  The attributes are passed to the main cluster of the custom device.  I would suggest (to keep things simple) to set the Interface:CAN:Termination property in the setTransceiver Vi in the start case.  In this VI, we read what protocol the interface is using.  That way, you won't set a termination on a FlexRay board using a CAN property...the downside is that you will need an input session, since you are only setting the property on the input session...If you want to be really complete, you can set the property on the output sessions as well.

I've made these modifications in a new version of the custom device.  Please note that not all the new features are fully tested, but the custom device functionality of 1.5 should still be there.  You can get the beta version here.  (The link will expire after some time since its on our FTP site...)