The header configuration dialogue for Tx packets must be opened in order to save the configuration. (I.e. the default configuration is likely not saved to the relevant custom device property.)

Any interest in adding an RX message counter for future a releases? I know there is a "New Data" Flag but a Message counter would be quite useful

There were breaking changes between version 0.1.0 and 0.2.0 of the VeriStand Data Library that improved performance. The source should be updated to use the most recent VIs.

Hello,

I installed UDP-Data-Link-Custom-Device to my Veristand 2020R4 using udp-custom-device-2020_1.4.6.001_windows_x64.nipkg,
I made a simple project to test the UDP communication. In system definition, I configured the UDP custom device as below.

Tx;
Src ip: 127.0.0.1 : 12902
Dst ip; 127.0.0.1 : 12900
channels config : testTxconfig.csv(sample csv on github)

Rx:
ip 127.0.0.1 : 12900
channels config : testRxconfig.csv(sample csv on github)

And then I linked the New data, Port, and channels data of Rx and Transmit, Transmitted data, to numerics item in .nivsscr (no setting in .nivssdf ), and deploy the project. From the attached picture, you can see the UDP should working and New data of Rx is counted up.

But when I try to modified the Transmit data of Tx, the transmitted data of Tx and channels data of Rx didn't change at all.
I wonder how I can set the Transmit data correctly and set the data to my channels in Tx. Many thanks!

Hello everyone,
Can VeriStand 2021R3 use this Custom Device?
If the latest version "udp-custom-device-2020_1.4.6.001" only supports VeriStand 2020, how can we realize the UDP communication function in VeriStand 2021R3?
If we will not continue to update UDP-Data-Link-Custom-Device, is there other useful Custom Device to replace it?
Look forward to your reply.
Thank you!

It would be a great addition if the Transmit Channel could be configured to trigger on the change of a counter instead just when non zero.

I must be missing something. I do not understand how the transmit line can reset to zero if there is a model channel mapped to it.

The transmit looping in the Custom Device Engine uses a millisecond loop timer for timing its outbound transmissions. This is true for both the buffered/unbuffered payloads.

The underlying effect of this is that at any PCL rate faster than 1kHz, the loop timing coerces to a value of 0 ms (effectively a NO-OP) for the transmit loops. So instead of matching the PCL(ish) in loop timing, the transmit loops will iterate as fast as they can and eat up a lot of additional resources on the target. This could be a significant extra utilization on high-speed systems that need those clock cycles for sim.

Dialog - Configure Packet Header.vi should not force Packet Size to be present. There are use cases where the packet size should not be part of the stream.

Action items:

Set default constant in Read Header Info.vi to 1

Remove Replace Array Subset in Dialog - Configure Packet Header.vi

Can this UDP custom device apply to the NI Linux RT system？

Hi Team,
In my use case, I'm using UDP Custom Device in integration with Ballard Arinc 429 CD. In this scenario, I'm getting an error during deployment (mentioned below). This error is not popping if I deploy UDP CD alone. Can you guys pls share your comments on this error and any possible workaround would help. I'm also sharing the Veristand project files incase of recreating the issue

UDP_Arinc429_Integration_Testing.zip

I cannot figure out what the diagnostic channels are or how to add one. Would you please add instructions to the help?

What are the reasons that my transmit count would be less than the transmitted count.

I am using Transmit Options (One-Shot) and Transmit Echo Options of Counter.

I keep seeing that I have a higher "Transmit" than "Transmitted"

I am seeing the U16 packet size in my data. I cannot remove packet size and it does not appear to be in the UDP headed but rather in my data. I do not see packet size when I use a buffer

Is there anyway to specify the length of the message? I think that would be a really powerful feature to add

Has any one had any luck programmatically importing the .bin configuration file? I am trying to do it in labview

I have narrowed down to the VI below.

I dowloaded the project from the main page.
Under My Computer / Build Specifications: built Configuration Release and Engine Release
Under RT PXI Target / Build Specifications: built Engine Release
In the VeriStand project, a UDP custom device created with transmit packet and receive packet. Sending UDP packets from the target works, but not receiving at the target.
Do I have to manually load the engine release on the target?
Where could the error come from?
I get this error message in the console viewer:
UDP-Custom-Device.VS Inline Async API.lvlib:Display and Log Process.vi:197
0001 CUSTOM DEVICE ERROR
UDP-Custom-Device.VS Inline Async API.lvlib:Display and Log Process.vi:197
0001 CUSTOM DEVICE ERROR
Source: Error 74 occurred at ??? in UDP-Custom-Device Engine.lvlib:UDP Rx Pro
cess.vi:840001->UDP-Custom-Device Engine.lvlib:UDP Rx Process.vi.ACBRProxyCaller
.D0000017
Possible reasons(s):
LabVIEW: Memory or data structure corrupt.
Code: 74

Hi, All.

I tried to use UDP Custom Device on NI VeriStand 2018 SP1.
However, I faced various problems.

- Missing Files in LV project dependency tree (all missing files are related with NI VeriStand Data library)

I already tried to install both 0.1.0 version and 0.2.1 version. However, both of them had a problem.

Please give me some troubleshooting steps for these issues.

Hi, I tried to build this CD for 2023 and it works on the local Windows target but fails to deploy on a cRIO target running NI Linux Real-Time x64 6.1.38-rt12.

Any help is much appreciated.

Did the ability to set decimation go away? If so and I need it, what can I do?

It seems that there is a push to develop custom devices now using packed libraries instead of dlls. Is there any thought of building this custom device using packed libraries. I tried to convert it myself and failed.

Who has a TCP custom device?

Hello All,

I'm running with the latest version of the UDP Custom Device, and was looking for a potential feature to be added if possible. I either need source ports to be shared amongst transmitted packets, or to have 'IP address' be available as a channel as well for transmitted packages, so it can be switched, like how the port channel is currently implemented for the tx packets.

I currently have a need for the tx packets to be sent all from the same source port, but to different destination ports and ip addresses. I was able to make a common source port via the buffered tx packet, but then was unable to change the IP address for multiple targets.

If I have multiple tx packets with different IPs, different destination ports, but the same source port, it gives an error on deployment. Again, the source ports need to be the same in order to work in my configuration, or I would have changed them to be unique.

Is there any clean way to have this custom device add and check protections like checksums and CRCs?

Hello,

I wonder if UDP custom device can receive and send the raw byte-array? The size is about 500-900 byte,

I have a model with byte-array (vector) input to decode the UDP Rx raw byte-stream and also output to UDP Tx with byte-array(vector), I want to use UDP custom device to receive and send the data as raw byte array.

It seems that there is only U8 data type in UDP custom device. I am not sure if the setting as below is correct or not.
For Rx

For Tx

Many thanks!

Hello,

I've implemented a few different instances of buffers in other programming languages, and I've always understood circular buffers as a 2-D matrix where the rows are the length of the maximum message to be received, and then the column being the depth of the buffer (or vice versa). Once a message is read in the buffer (assumption of read each cycle if buffer is not empty), the next message moves up the queue and an empty message is moved to the back. Another means is by just overwriting each message as the buffer fills, instead of deleting and re-adding an empty column.

The only reason I mark this as a potential implementation, is because using the circular buffer, I'm occasionally seeing collided data (data seems to be from two different packets). When compared to wireshark, i'm not seeing corrupt packets, or invalid data. My thought was a split packet due to overflow, but the code description explicitly states a packet will not be split. My thought is to separate the packets entirely, and then we will not see the potential corruption.

Hi. When trying to add UPD-Custom-Device to Veristand, an error occurs:

_Error 7 occurred at Open VI Reference in Custom Devices Storage.lvlib:Initialize New Custom Device.vi
Possible reason(s):

LabVIEW: File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.

Nonexistent GPIB interface.

VI Path: C:\Users\Public\Documents\National Instruments\NI VeriStand 2017\Custom Devices\UDP-Custom-Device\Windows\UDP-Custom-Device Configuration.llb\Initialization VI.vi

Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.

LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets._

I think I am going wrong with the installation process. Is there an instruction on how to properly perform the installation process and add a custom device?

I seem to be having issues when I receive multiple messages on the same port at the same time. I have a buffered packet receiving multiple messages on a port with a circular buffer. I can see the "New Data"counter incrementing by the number of simultaneous messages I am am receiving but the 'Bytes Received" is always static at the size of my largest message. It does not seem like I am filling my buffer but I am certainly dropping data. I think I just get one message per loop and drop the rest. If I monitor my buffer, it looks like I am only updating the values of one message per change in "New Data" the the location of that data in the buffer changes.

All I am trying to do is to forward incoming messages from one port and IP address and send them out another, I am using a buffered packet with a circular buffer.

When adding the custom device to System Explorer, I'm getting the following error. I've downloaded multiple versions of the data library, but have not been able to get this error to go away.

Error 7 occurred at Open VI Reference in Custom Devices Storage.lvlib:Initialize New Custom Device.vi

Possible reason(s):

LabVIEW: File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.

NI-488: Nonexistent GPIB interface.

VI Path: C:\Users\Public\Documents\National Instruments\NI VeriStand 2015\Custom Devices\UDP-Custom-Device\Windows\UDP-Custom-Device Configuration.llb\Initialization VI.vi

Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.

LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.

If two or more Tx Packets are configured with the same IP Address and Port, the UDP Open will throw Error 60 when deployed because the engine calls UDP Open for each Tx Packet and the UDP Open reports that the socket is already in use.
Users should be able to define multiple Tx Packets that share the same IP Address and source port.
An additional requirement is to allow for a mix of Tx Packets that share the same IP Address and other Tx Packets on alternative ports while managing the UDP Open correctly for these combinations.
There are two ways this could be improved:

1. Execution only: Create a session manager wrapper around the UDP Open and UDP Close that keeps track of the used IP Address and Port settings along with the connection ID reference from UDP Open. If UDP Open is subsequently called with an already claimed IP Address and Port, simply return the existing connection ID reference instead of trying to open a new socket.
2. Handle multiple Tx Packets with the same settings in a similar manner to the Duplex handling when an Rx Packet and Tx Packet share the same settings. The Find Duplex.vi searches for matching Tx Packet and Rx Packet IP Address and Port settings and creates a Duplex Packets structure with the matches. This is used during execution to skip the call to UDP Open and reuse the Connection ID. Multiple Tx Packets with the same IP Address and Port could be handled in a similar manner. This option would allow a user interface confirmation that the user intended to reuse the existing socket which may not be necessary.

there are two vis: Byte Buffer.Set Buffer.vi and Byte BUffer.Get Buffer.vi cannot found