M_P

Not being dumb, but also not experiencing unexpected behavior. It is different than what you might expect from just running the code on the local Windows system. This behavior boils down to the fact that you are viewing a remote representation of what is running on the remote system, separated by a transparent communication layer that relays front panel and probe values back to the Windows machine you're viewing it on, rather than the actual front panels. You can get (2) to work if you enable the embedded UI (assuming it is a cRIO unit that supports embedded UI like the 903x, 904x or 905x) and connect a monitor to the display port of the cRIO. Unless you're in direct dev/debug of the RT code, it is usually a better design approach to assume the RT code is headless and structure the user interface accordingly. This is actually such a common snag that users hit that NI added VI Analyzer tests for the RT Module a few years back (2014, I think?), and the top item in that test suite is usage of front panel property/invoke nodes.

Much like a shared data plan. With associated overage charges if you're not careful.

I highly recommend *reviewing* the sample projects, as there are useful design patterns to learn and emulate, but the effort involved in refactoring the sample projects to meet the exam requirements is usually higher than writing code from scratch that follows a similar design pattern but directly matches exam requirements. Bear in mind with this exam that it is primarily graded on functionality (50%) and design (30%), with style (15%) and documentation (5%) worth much less. Compare this to the CLD, where style and documentation are collectively worth 25 out of 40 points (62.5%). Your strategy for time management during the exam should reflect this. I wrote the sample exam for the CLED, and the solution provided is what I coded in 4 hours of time (yes, including the icons). I expect, like MKerry says, that if you could finish the sample in about 5 hours that you're on track to do well on the actual exam. The sample is more complicated than the actual exam.

I'm in need of some use cases/requirements for actual LV applications that need 0MQ, AMQP, or similar middleware so I can justify spending additional time on this. I'm working on messaging/data distribution architectures in my spare time, but spare time has been increasingly difficult to come by. If any of you fine folks have requirements/use cases/application details that you can share with me, I'd appreciate it if you can send them my way. Specifically, what is the value you see in these libraries that is not met by existing LabVIEW libraries/capabilities? What kind of data distribution are you doing with them (and does it fit into some combination of tags, commands, and streams)? Are your data types static or could they change arbitrarily? Do you have a brokered approach, and if so what drove the requirement for a broker? (Centralized logging and alarming, abstraction point between control nodes and HMI nodes, etc) What directionality is the data flow? One-way producer->consumer, mesh broadcast, two-way command handshake, etc If posting publicly is no bueno, matthew.pollock@ni.com

I had great fun digging into the depths of the fancy schmancy messaging protocol I was designing, until I discovered that it already existed, was called ZeroMQ, and was implemented better than mine was. That was simultaneously sad and exciting. I'd love to see a comparison between the different languages (ideally with the code to reproduce) - I'm trying to work up some recommendations for customers choosing what messaging architecture to use for a large mostly LV system.

I figured somebody had to have already done this - it's too enticing of a project not to. Would you happen to have actual benchmark data or code that you'd be willing to share?

I'm particularly looking into this (I'm also known as MattP on the NI forums, I work in the SE group like GoGators). From my perspective, it fills a gap that was partially filled by the AMC library (using same API for inter-loop and inter-node communication), network streams (automatic reconnect in background abstracted from the read/write, good performance), and shared variables (the pub-sub use case). What it handles better, IMHO, is that it handles not just the reconnect, but also the initial connect and intermediate send/receive queues entirely asynchronously. It also easily handles N:1 or 1:N using several different transports. It's not so much the base set of patterns that are useful, but the combinations of them that perrmit complex problems to be solved with very small quantities of efficient code. Me likey. Currently I don't see support for ZMQ on VxWorks, which makes usage on cRIO rather tricky, and I know it hasn't been tested on Pharlap but 'appears to work.' I'm contemplating either liberally borrowing the design philosophy of ZMQ for my own comms framework (which would not be easily usable with non-NI tools but would permit NI-specific transports such as FPGA DMA FIFOs), attempting to port and test the C source over to VxWorks, or possibly to attempt a full ZMQ implementation in native LV code.