MarkCG

update to this thread: we got it working on the cRIO 9068. See this thread https://sourceforge.net/p/labview-zmq/discussion/general/thread/87780372ed/ for details. Thanks to everyone here and Martijn Jasperse for all your help.

thank you Rolf and SmithD, this helps. I think he is making some progress now by compiling on the cRIO although it's not working yet. I've informed him of this thread and will update if we can get it working!

Turns out one of my coworkers is trying to compile zeromq for the cRIO-9068, but not having success. Anyone ideas or have the .so file available? We also have a cRIO-9038 which is a different processor architecture, maybe it will work there?

I was going to say beckhoff as well. I'm a big fan of the beckhoff "EtherCAT Box" series. https://www.beckhoff.com/english.asp?ethercat/ethercat_terminals_accessories_overview.htm . Very reasonably priced too and you can get rid of enclosures.

What is the datatype you want to write? If the manual for the device say that a particular register is interpreted as a 16- bit signed integer (I16 ) you will need to use the type-cast function on the I16 data in your LabVIEW program and wire that that to the write single register VI. For single precision floating point values, which are 32 bits, the modbus device will typically have you write to two consecutive registers in memory, typically called the high word and low word. It's done this way because every modbus register is 16 bits. So what you do is this and wire the array of U16s to the "write multiple registers" VI. Usually if the high word precedes the low word in memory this will work. If not the you have shuffle the high and low word. Modbus is fairly old, dating back to the 70's and doesn't have built in support for flaoting point.

Unfortunately you probably have to make a voltage divider but the Winford enginering terminal blocks are pretty useful for this because you can solder in your divider resistors and then connect the block to the module with a d-sub cable https://www.winford.com/products/brkdd37mf.php

Fair enough. I will say that the old library did the job pretty well though, never had a problem with it, even running on something as old as a fieldpoint. I actually modified to make it faster on reads as well, and also to make communications library for a flowmeter that used a proprietary bastardized version of modbus. The core logic of it is pretty solid and worth looking at.

Just curious, but why bother when there are multiple native LabVIEW implementations already? There was the "original" NI library , the LVOOP NI implementation, and I believe at least one third party implementation.

I actually think it has survived in a certain form--- it looks like statecharts are used in programming the new functional safety cRIO modules http://www.ni.com/white-paper/53844/en/

Do you guys think that sending the automated error report to NI after a hard crash actually helps them fix things ? I usually click no out of instinct but may be I should start. It's hard to believe how much we put up with LV's hard crashes-- for me a couple a day is no big deal. But otherwise they seem pretty rare in other programs nowadays. Chalk it up to the crustiness of the codebase I guess.

I've been experiencing a lot of crashes with 2017, way more than with 2014 which is what I was using before. Why or how they are caused I can't say.

The DSC toolkit Glyph really are pretty horrible. More 1995 than 2002 if anything. I've been using Edraw max to create graphics. There is a lot of P&ID stuff in there. No high vacuum but it's pretty easy to create graphics from the raw shapes and apply color gradients to give it that 3D effect. The ability to scale easily because of vector graphics is awesome too. You can set you drawing sizes in pixels directly which make it really easy to design for a given resolution. https://www.edrawsoft.com/pid-examples.php I will typically make a P&ID with edraw, export it as a PNG, drop that directly in the front panel and then drop my customized controls with graphics also made in Edraw in place over that. It's produced pretty decent results.

thank you, I am trying to get some more insight into what happens under the hood. I have noticed some cpu spiking behavior when switching between tabs of a tab control on a cRIO embedded UI which actually caused a scan engine timed loop to miss. Not important as far as the application was concerned but it got me me thinking on how to exert more control on what the UI is doing.

DataGridView.lvclass:Set Cell Enabled State.vi . You have to iterate over the cells to disable the columns you want. Now as far as setting individual cell values programmatically without restarting / redrawing the whole table, does anyone have an idea? Nothing seem obvious

Say you have several VIs that you are inserting into a subpanel display as pages, as an alternative to making them pages of a tab control. Say those pages each have I don't know something that requires more than average CPU to draw like an X-Control that's getting updated a decent rate. Does LabVIEW use resources to redraw each of those diplay elements if the front panel is closed in this situation?