Leaderboard

I'm no longer with NI (as of 2014!), but I just got notification on this thread. I'll forward it to someone who's still there and ask them to respond.

I've seen people add LabVIEW to their resume with less experience then that.

That's a mighty fine VM you got yourself there. Almost like having a VM of this Linux RT target is a super useful tool, that helps troubleshoot and debug features of the embedded UI that are at times "inconsistent" as you put it. For anyone else that finds this useful you should go vote on the idea, and/or contribute to the conversation.

I can only see a link to a request page, where only Pro users can make a request to presumably get older versions. There's no link to just get an older version that I can see.

Are those front panels part of your intended Embedded UI, or only for debugging? When I run VIs on the cRIO "from source", both (1) and (2) work correctly for me on the cRIO's screen but not on the PC's screen (including preallocated re-entrant VIs). Tested with LV 2017 SP1 + cRIO-903x image in a VM. It is always worth having the cRIO screen visible during embedded UI development because what you see on the PC is not what you get on the cRIO: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LZ9SAM

I work with those CURSED USB to RS232 adapters nearly every day and have had a whole range of different issues with them. I won't get into it all here, but here are the troubleshooting steps that I typically do in no particular order: 1. Jumper the Tx and Rx pins on the connector closest to your device to form a loop back (pins 2 and 3). 2. Use PuTTY or some other method to send data out, you should get the exact same data back. If you get data back, then you're communication is making it round-trip to at LEAST the connector of your device. 3. Try a null-modem cable/adapter, which swaps the Tx and Rx pins between one end of the cable to the other. Sometimes manufacturers don't make it easy to figure out if it's required. 4. Double-check to make sure your Baud rate, data bits, stop bits, parity and handshaking have been configured to match what the UPS is expecting. It looks like you're specifying a termination character for READ (For the initialization, 0x0A), but not enabling it. If the UPS requires a termination character, you'll have to explicitly send one with writes, it doesn't automatically append. If the UPS is expecting it, you may have to add an "0A" to the end of your hex string. 5. Look in the documentation to find out if the UPS requires any special termination characters, start/stop, etc characters - I.e. is what you're sending properly formatted? I've had devices which required unusual starting and termination characters before, with or without the common "0x0A termination character. 6. Your VISA Open timeout is zero, try adding something a little longer... possibly 50ms to 250ms or so.

After what I've read in this thread, I think there may be a bug here. I've filed CAR 440207 to investigate this behavior. I'll update this thread when I hear more information. While I understand and appreciate hoovah's sentiment that you should just trust the compiler, I think that blindly trusting it is not always the best idea. There's a lot that can go wrong. It almost always does the right thing. And it reflects well on LabVIEW that you trust it so much. But sometimes it doesn't do the right thing. It's important to look at LabVIEW with a critical eye sometimes.