Transmit Channel

[rdp137]

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.

[ryanvallieres]

I actually did a little bit of investigation on the transmit channel just now.

The transmit will definitely reset if you don't have another source constantly driving it to a non-zero value. In your case, the model channel mapping will hold it to a non-zero value. As such, it will transmit as long as your model holds that value.

As a minor note, I've noticed the transmit flag actually causes two transmits to occur. One when the channel value is set to a non-zero value, and one when the CD attempts to reset the value to zero. I'm hoping to patch that today on my own fork.

[ryanvallieres]

Additional follow-up: The transmit flag will actually cause the packet to transmit on any value change. This isn't clear in the documentation (or outright contradicted by it).

Upside, I think this actually helps your counter use-case. Not actually sure when I'll address the transmit on internal reset to 0. The API I'm using is making this slightly more complicated to address.

[ryanvallieres]

Update: I released version 1.2.1 on my fork. This should have updated documentation on the behavior of the transmit flag. Additionally covers an issue with the direction of the buffer channel when importing a configuration file.

[rdp137]

Any chance you could provide a simple VI example on how to use a pointer to fill the buffer created by this custom device? Everything I try results in a major crash. I am trying to run on a Linux64 cRIO if that matters

[ryanvallieres]

I just used the Veristand Data palette and a really simple custom device to demonstrate it. I'll see if I can get you the source for that CD, but it might be worthwhile to bother NI about it (note: I'm not NI. I'm actually an engineer for Bloomy).

There is a minor discrepancy in the pointer storage in the HTML documentation (which I need to resolve). I'm using a raw typecast to shove the pointer into the double. The size of the pointer will be dictated by the bitness of the OS (which is 64-bit in your case), resulting in use of any number of relevant bits in the channel double.

As for storing/reading the pointer from the channel, my best suggestion would be to use the 'Type Cast' vi in the Data Manipulation palette with a U64.

[rdp137]

are you suggesting that in my model that writes data to the buffer, I use a double as aninput for the pointer and then just type cast it to a u64?

I am still doing something wrong and I manage to just crash my cRIO every time I try to deploy

[ryanvallieres]

That's the basic idea. The input should be a double, and then in the model you can handle casting it a U64. Same goes for any pointers you want to expose externally.

Without me getting too deep into the specifics of your system, it's hard for me to say what else might be wrong. Have you tried doing this series of operations in the RealTime without Veristand? I'm not sure how the Veristand Data toolkit performs on a cRIO linux target.

[rdp137]

I think I am getting closer, however when I simply deploy this custom device set for a buffered transmit. I do not see a value in the "buffer" channel. I would assume it would be non-zero

[ryanvallieres]

You should see a non-zero value. I'd suggest making sure the 'External Buffer' property for the TX packet is not set (assuming the UDP Custom Device is sourcing the buffer). Additionally, I've seen issues trying to view the channel value when the UI Manager indicator is set to a non-double data type.

[rdp137]

I can confirm that the value is zero and external buffer is not selected. I am not using the UI manager. I think this has been the cause of my problems. trying to write to a pointer value of zero is probably not good. What could I be missing?

[ryanvallieres]

Hmm... that's a tough one. Are you on the latest release of the custom device? It just recently got updated from my personal fork which I've seen work correctly. The UI Manager is just a convenient way to observe a non-zero buffer.

Some other things you can try:

• Make sure the buffer size is set to a non-zero value.
• Verify that your network settings are correct

I've also attached a config file that should be compatible with the latest release. It definitely creates a pointer and makes a non-zero value in my testbench.

txBufferConfig.zip

[rdp137]

using the version I downloaded just now and this txBufferConfig file. In a sys def file with nothing else. I only get zero in the buffer channel. Running in either windows or on the cRIO.

[ryanvallieres]

So, just for my own clarity, the custom device looks something like this:

But when you run it in VS2018, it produces a null value in the buffer channel?

[rdp137]

that is correct. It produces a value of zero

[ryanvallieres]

Got it. I suspect it has something to do with the integration into VS2018. I need to get a testbench setup for this, but I'll take a look into it.

[rdp137]

Seems like creating an external buffer also results in a crash

[rdp137]

if I setup the custom device for an external buffer and I uncheck "Always Transmit?" it will not crash on deploy, I can even use the channel data viewer to make sure the pointer value is non-zero. I do get an error as soon as I trigger the "Transmit" Channel. I see the following error over and over in the Error log

mode: "VI_BROKEN";
callSite: "CheckVIRefsForMissingDependencies";
timestamp: "2019-05-02T10:58:21.925332";
vi: { name: "Data Access Engine.lvlib:Data Access Engine.lvclass:Data Access Engine.ctl"; path: "/c/ni-rt/VeriStand/Custom Devices/UDP-Custom-Device/UDP-Custom-Device Engine Linux64.llb/Data Access Engine.lvclass/Data Access Engine.ctl";}
missingRefees: [ { refType: "VIPI"; refIdent: { name: "Data Access Engine.lvlib:Read.lvclass:� "; path: "/c/ni-rt/VeriStand/Custom Devices/UDP-Custom-Device/UDP-Custom-Device Engine Linux64.llb/Read.lvclass";}; },
{ refType: "VIPI"; refIdent: { name: "Data Access Engine.lvlib:Write.lvclass:� "; path: "/c/ni-rt/VeriStand/Custom Devices/UDP-Custom-Device/UDP-Custom-Device Engine Linux64.llb/Write.lvclass";}; },
{ refType: "VIPI"; refIdent: { name: "Data Access Engine.lvlib:ReadWrite.lvclass:� "; path: "/c/ni-rt/VeriStand/Custom Devices/UDP-Custom-Device/UDP-Custom-Device Engine Linux64.llb/ReadWrite.lvclass";}; }

[ryanvallieres]

I haven't had the time to get my VS2018 test together yet, but this is somewhat more telling of an issue. There's definitely some kind of dependency problem that needs to be resolved. I'll see if I can run the error by some of the other VS experts 'round here and if they've seen it.

With some luck, one of them will and I might be able to give you a solution.

[ryanvallieres]

Best I have right now is that one of the dependencies of the inline async custom device template isn't deploying to your target correctly. Upside: Not explicitly an issue with the UDP CD. Downside: Your app still doesn't work and you need to figure out why that library isn't deploying.

Have you tried building the LLB from the source directly? Additionally, it may be worthwhile to just verify that the LLB has no issues when viewed/opened on your target in development mode.

[rdp137]

I am not sure what LLB you mean

[rdp137]

I have also observed that if I try to run the CD on windows, it still does not seem to create the buffer pointer. However, if I just use channels instead of buffered data, the CD works just fine

[ryanvallieres]

When you compile the custom device for a target, it's being compiled into a flat, single file format (the LLB). This LLB is stored locally on your host computer in some directory specific to what Veristand required. EG:

C:\Users\Public\Documents\National Instruments\NI VeriStand 2016\Custom Devices\UDP-Custom-Device\Linux_x64

When you go to deploy a Veristand system definition, all these custom device LLBs are deployed to the target. The error code you shared appears to imply that there are missing files from the LLB. From checking my own compiled copy of the LLB, those particular files are not missing.

I'm not immediately sure why the channeled-version of the CD isn't producing the same error. The buffered version and the channel version are largely identical in implementation.

[rdp137]

Yes, I can verify that I have rebuilt all the LLBs with "NI Veristand Data" Library 0.1.0.2
I am using channel data viewer and a indicator on the workspace to see that the value of "Buffer" remains 0 after deploy. It is set to always transmit with "Transmit Bytes" set to 10. I have tested on both Windows and linux64

Sorry for all these questions

[ryanvallieres]

Alright, I finally got a Windows-side testbench setup for the UDP CD in VS 2018. I'm seeing my buffer channels populate as intended and data transfer in/out of the buffers correctly. I've attached my own compiled Windows Custom Device to this post.

Windows.zip

[ryanvallieres]

Best I can tell, there's either a missing dependency in your system or there is a problem with your builds. In an alternate theory, there's something unique about your test computer as opposed to mine. Not terribly certain myself what is causing your system to die.

[rdp137]

I think I solved the issue with the buffer value. In Init Bfr Tx - Create Buffer.vi. Using Type Cast to put that pointer value into the veristand channel array doesn't seem to work. It outputs a tiny value. Replacing it with "To Double Precision Float" seems to fix the issue. I have verified that I can now read and write to the buffer the CD creates and it transmits data. I assume I need to make the same fix in other places.

[ryanvallieres]

Interesting. I guess I don't see why it wouldn't work, as long as the value you put into the channel is the same one you read out in your model. The Type Cast was meant to literally dump the U64 pointer bits 1:1 into the double channel, avoiding any potential loss of value due to the formatting of double value.

The 'To Double Precision Float' should technically work too, but I'd be concerned about getting the wrong value back out of the double. If it works for you and your model is happy with it, that's good to know though. I can investigate it directly and see if it's a stable implementation.

[rdp137]

I noticed the same issue when I was going from model to model and in LabVIEW by itself. Could it be because I am running 32bit Labview?

[ryanvallieres]

It's possible. It may be that 32-bit LabVIEW will only ever create pointers that use 32-bits. That's territory regarding how the LabVIEW memory manager creates pointers, and how it interacts with the Windows OS. It's plausible that the low-level DSNewPtr in the VS Data toolkit is doing something slightly different than a malloc/calloc call.

I'm not really sure at this moment.

[ryanvallieres]

As far as I can tell, LabVIEW 32-bit will only allocate pointers that are 32-bits in size. Which is probably why the 'To Double Precision Float' works for you. Still makes me a bit uneasy though. Super easy to observe if you just call the 'New Pointer' function a whole bunch in a VI before closing the pointers. It makes a bit of implicit sense, since 32-bit LabVIEW can only handle 32 bits of addressable memory, and has no business allocating pointers that might use space outside of that 32 bits.

Regardless, your models and other software stacks will likely need to be conscious of that fact if they're going to exchange pointers via channels. Not sure what implications this has on your model code you want to have running on the cRIO either, since that's possibly running in a 64-bit domain and has to play nicely with a 32-bit domain.

[ryanvallieres]

Hmm, actually I think Veristand is fundamentally 32-bit. And all the models that called by it end up operating in a 32-bit domain. So I guess your models just need to be cautious about trying to use pointers in a 64-bit representation.

[ryanvallieres]

Just as a heads up, the 1.3.2 release supports using conversions to store pointer references. I believe this is how you @rdp137 updated the CD for channel support.