Showing results for 
Search instead for 
Did you mean: 

Control to monitor serial bus traffic

Go to solution

Just started getting my hands dirty with an eval of Veristand.  My tinkering is going well, but I have noticed a potential problem for when I start developing my own stuff for my program.  Hopefully, some one can point me in the right direction.


If I'm understanding things correctly, data is passed between target and host in scalar DBL form.  If the user changes a Boolean to TRUE, then the host transmits a 1.0000 to the target, etc.  I will need to be implementing a set of unique proprietary CAN and Ethernet protocols in a Custom Device.  For items such as "Engine Speed" or "Switch State" this won't be a problem.  However, this protocol includes the ability to transmit multiple fault codes, with their timestamp, and count.  Also, the customer usually wants to monitor bus traffic as well. 


I don't see how I can transfer cluster (or array of cluster) data to the target for transmission, or variable-length message data back to the host for display.  Has anyone tackled this issue yet?  Any elegant ways of doing this other than defining channels for each and every possible byte of data that could be received?

0 Kudos
Message 1 of 4



I am going to take a stab at this, but I will consult with others here at NI for a more complete answer....


You can create a custom device for the RT side that will read from VeriStand channels and input them into a shared variable that you define (or use STM). You could then create a custom workspace tool that will read those values from the network. It's essentially making custom bus monitor. However, to use those values as part of the VeriStand Engine then mapping through channels will be necessary.


My $0.02 worth for right now, I will check more with others here at NI....



0 Kudos
Message 2 of 4

Thanks for the reply, DiscoBall. 


Been playing around with the Veristand architecture for the past few days in an effort to come up with ideas.  It appeared to me that the best way to do this would be to circumvent the normal data path.  The only solutions I could come up with staying within the normal Veristand architecture involved lossy transmission, a huge number of channels, and an inelegant design.  I figured that something like STM would work, but I was hoping that I could do something easy like Shared Variables.  Can you verify that SV's will deploy and function in the Veristand environment?   It doesn't seem obvious to me that it would least not as obvious as an STM solution.



0 Kudos
Message 3 of 4
Accepted by topic author thisisnotadream

Hi Dan,


Shared variables will work, you just have to manage the deployment from a LabVIEW project, then you can monitor with Distributed Systems Manager. You can write to them using a Custom Device and using the Shared Variable palette or creating the RT target in the Custom Device project and working with them there.


Another possibility is to use an Engine Component:  You can configure Engine Components in the Environment Settings dialog for a rig file. An Engine Component is launched automatically whenever we connect to the RT Target. It does not need to be invoked from the Tools menu.

An Engine Component does not have to have a special connector pane or anything. It can be any VI. The only special functionality it has is the ability to provide some synchronization options when running the workspace. The Workspace can be configured to have the following sychronization options with Engine Components:

None: Start up the Engine Component but don't wait for it to do anything
Wait Sync: Wait for the Engine Component to fire a boolean notifier before continuing and opening the Workspace. This Boolean notifier reference must come from a Front Panel control called Engine Sync.
Wait Complete: Wait for the Engine Component VI to complete its execution before continuing and opening the Workspace.

We do ship a template Engine Component with VS2009. It is located at: <vi.lib>\NI VeriStand\Engine Component..

0 Kudos
Message 4 of 4