ScottJordan

It's a Microsoft problem. See http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/ This is not just a LabVIEW problem. Bottom line: LabVIEW 64-bit requires 64-bit .dlls. Because Windows. The 64-bit transition in Windows was an unholy mess. Consider that iOS went 64-bit in 2013 ...and nobody noticed, even though the hardware is far less compute-capable than your average Windows machine. There's really no excuse for the gibbering chaos that is 32-bit .dlls in 64-bit Windows. Try 32-bit LabVIEW? Your license entitles you to both versions, IIRC.

Event structures are driven by user-interface events. A programmatic change to a control's value is not a user-interface event. But you can write to the "Value (signaling)" property instead; this mimics a user-interface event and will trigger your event structure. By the way, I suggest you put a delay in each of your loops. Otherwise they'll run as fast as they can, which will bring your computer to its knees. For the simple While loop, a Wait (ms) subVI will do; any non-zero value for the wait will keep your computer happy. For the loop containing your event structure, you can wire a non-zero positive value to the hourglass icon at the upper left corner to achieve the same thing.

Manudelavega notes, "...for those of us who have been developing in LabVIEW for years, a wire always controls data flow and execution. This is a golden rule that suddenly doesn't apply anymore, and that's quite disturbing I find." Others have expressed similar concerns in different ways. But: ​That ship sailed circa 1987 when global variables first became a thing. (A few of us were using uninitialized shift registers even before that.) Dataflow is central to the LabVIEW way of doing things, but purity was sacrificed on the altar of power and functionality at that time. The real question is whether there's a use case for this particular innovation, and whether this provides a more sensible and LabVIEW-ish way of representing what's going on. I suspect that if you've done much with queues and suchlike to take advantage of LabVIEW's awesome parallelism capabilities, you'd probably feel it does. I have, and do.

Filipe & Team, Congratulations on the successful launch of the Arduino Compatible Compiler for LabVIEW! I'm among your first paid customers and am very impressed with your accomplishment. What is the mechanism for providing feedback and feature requests for future releases? (Top among them for me would be a timed loop, ideally one with very fine timing capability.) Hope to see you at NI Week. Best, --Scott Jordan

Hi again Tom, Since I won't know if you posted something here, feel free to email me at scottj "at" pi-usa.us, either with questions or to alert me to a new post here. Thanks & good luck. I think you'll like our LabVIEW drivers-- they are very complete and consistent from instrument to instrument. Best, --Scott

Hi Tom, I am a LabVIEW user for more than two decades and currently work for PI. PI offers a very nice LabVIEW driver for E-516. You do not need RT. You can use PI's driver to communicate with this instrument via RS-232 or GPIB. Let me know if you prefer to do analog interfacing, as we have a solution for that too. Contact your local PI office for a copy of the driver and other applications assistance: http://www.physikinstrumente.com/en/contact/subsidiaries.php Best regards., --Scott Jordan PI