MarkCG

Daniel, thank you so much for sharing this and bringing it to my attention. So what someone would have to do is create a program that reads in a protobuf specification text file, and then uses VI scripting to create a VI that encodes a specific message, using the VIs in the library "protocol buffer encoder". Seems like the sort of problem that you can break down recursively-- once the protobuff specification is parsed into a tree. you start at the root and recurse down the tree till you get to a leaf node. Generate code for all the leaves, then as you recurse back up wire the leaf code together. Easier said than done though...

how are protobuffs that different form flattening a LabVIEW cluster ? It seems like I may be implementing LabVIEW protobufs at my job. I keep checking this thread hoping someone will have done it already, because it really has very little appeal to me as a project, but I may have to.

A LabVIEW programmable PLC for $99 + $59 per I/O module? This shouldn't be an April fool's joke

All I/O goes through the FPGA, and you can program a cRIO with both a program running on cRIO real time processor and one on the FPGA (also called a "personality") . You do not however HAVE to explicitly program the FPGA. You can use the "scan engine" if all you want to do is read and write I/O at a rate up to 500 Hz or so. All your program logic can be done in a LabVIEW program running on the real time processor. Where the FPGA comes in is when you need to do things at high speed, or with very high timing precision . For example, you want multiple PID loop controllers that run at 10 kHz, reading an analog input as the process data and outputting the control signal on an analog output or as PWM signal. You can do this on the FPGA-- you wouldn't be that fast otherwise. That or doing things like responding to digital triggers to perform some action within microseconds, things that generally require you to access I/Os on the in microseconds. You can also use the FPGA built in digital signal processors to do things like fourier transforms of data coming in and a whole myriad of other signal processing things that's contained in the Xilinx IP that you can access on some cRIOs. You are more limited in the datatypes and functions you can use on the FPGA-- typically you do things in LabVIEW fpga code you would not do in normal LabVIEW. On the real-time side of the cRIO, you can do pretty much anything you do on a normal computer with far fewer limitations-- you have access to the internet, serial communication to instruments, all the various math and analysis VIs, pretty much anything except UI related things (unless you have cRIO with a display port) The host is generally just the thing you use as a user interface. PC, tablet, phone, what have you. Typically the cRIO has the machine's logic built into its real time program, and the "host" sends commands or makes requests of it to do something via TCP/IP, network streams, or even UDP. The cRIO handles those requests and then lets the host know whether it can do them and whether it did or not.

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.