I inherited a project last year that uses a cRIO, it's my first time using one of these. Since then, almost every time I use it is an uphill battle. If I want to deploy working code it takes about 4 hours brute-forcing different combinations of Connect, Deploy, Launch, Reboot and staring at this sort of screen: Here are the frequent problems I have: NI MAX is slow and buggy, but it holds the keys to the kingdom. I keep this open to keep an eye on CPU and Memory. Sometimes clicking "Refresh" will hang the cRIO or hang MAX itself. "LabVIEW: (Hex 0x661) The LabVIEW Real-Time process encountered an unexpected error and restarted automatically." Connecting to the cRIO will sometimes fail with nondescript errors or hang for 10 mins until I Cancel. Deploying Shared Variables to the cRIO fails about 1/4 of the time, again nondescript (or the whole cRIO will hang). Finally, Launching my VI will sometimes fail unless I go and explicitly clear the cache and restart LabVIEW a couple of times. All in all, it's a frustrating waste of time - how has your experience with cRIOs been, and do you have any workarounds to this unreliable deployment platform?

You made me smile so hard! I did cRIO dev for 5 years and it was always the same but it slowly improved up to 2021, which I use now. I add three fails that annoyed me with cRIO: Shortly after launching an app, probably during initialization of FIFOs, queues or FPGA, LabVIEW disconnected from target with popup "target was disconnected". Sometimes reconnecting threw you back into execution, sometimes not. Sometimes it happened everytime, sometimes every second time, sometimes never. Never found why. Firmware change, drive formatting, installing software, if not performed after manually enforcing Safe mode, took 10-15 minutes until an error window popped up. This occasional unability to perform a software reboot is there at least since 2017. File sharing with Windows (SFTP?). The file contents are cached for about a minute, never found a way to change it - you can see the log file size growing in Explorer but you must wait for a minute to see the changes in opened file. And establishing the connection takes about 40 seconds, during which your Explorer or TCmd window is stuck, so I often found myself just randomly entering a directory like every minute just to maintain the connection. I must say that these network issues are worse when connected with Ethernet-over-USB. Network stability probably plays a role. Also make sure to "Disable RT App on Startup" when developing. Use something else to get CPU and Mem info. I used bash logger script, or you can use NI Distributed System Manager, which for me worked at about 40% of cases. Good practice when developing a feature for a longer time is to clone your top VI and then removing the unnecessary parts for testing - it speeds up everything. Don't keep multiple targets in a project even though you can - opening a project takes a lot less time. Oh, I almost forgot. It happened to me I think three times. Something went wrong with a VI file and while there were no problems running through the LabVIEW project, the app failed to run as startup. No error. Of course that it always came up like one day before departure to customer. I desperately looked everywhere in linux, found all the empty or nondescriptive logs... No git back then. So I deleted half of all the loops and tried. Nothing. Then the other half. App started. Added a quarter of deleted code. Not worked. You see where this was going. So by performing bisection method on code (with iteration taking 5-20 minutes) I found a VI, actually one single element (once it was a diagram disable structure) which when removed and placed anew fixed the problem. When it happened for the first time, I fixed the problem at 3 am of the second day, oh boy. PS: The real IT guys frowned when I told them to restart a Linux computer with "reboot;reboot" command. Vit