Jump to content


Popular Content

Showing content with the highest reputation on 01/28/2015 in all areas

  1. 1 point
    Hi guys; Check out what we are doing with LabVIEW and Arduinos. http://www.tsxperts.com/arduino-compiler-for-labview/ We created an actual LabVIEW compiler for Arduino targets that allows Arduinos to be programmed in LabVIEW. Figured to share this with the community. Cheers Filipe
  2. 1 point
    Lisa, welcome to LAVA! +1 for posting the announcement here. To all who have never joined the LabVIEW Beta -- this private forum Lisa mentions used for Beta discussion is an excellent resource for the latest in-depth LabVIEW topics. LabVIEW R&D historically has been active and responsive on this forum, and it's your opportunity to influence the product while there's still a little churn remaining before release.
  3. 1 point
    Okay, Norm, I'm soon to embark on a journey through your minds. I'm planning on refactoring an automated test system into using TLB`. Generally speaking, the current program takes a start command from a front panel button OR a boolean output from a VI that runs in a loop that samples an input to a DAQ from a switch. Then it goes through a series of steps like engaging a couple solenoids, reading from a laser displacement meter while adjusting a servo, making adjustments to device parameters, and displaying and logging results. To put it in your framework (tell me if I'm mistaken), I would trigger the start by either an event that catches the start button press and fires off a trigger to "start test", or by having the VI that reads my DAQ's switch input live in the "Idle" action case of the main loop and - what? Have a case in the idle action that sees this and enqueues the "start test" trigger itself? What about subsequent test steps? Should I have the "start test" system trigger case in the idle state case enqueue "first test step, update display" into the action engine (terminology?), and "testing" into the state, etc? Or should I have the transition completion after each action while in the "testing" case result in an "update display" action, possibly using an element in the mothercluster to signal to provide the next step in the test? I guess what I'm really getting at, is how to I intersperse regular display updates in with the steps of a test sequence, or, how do I keep the sequence running without enqueuing all the actions at once when the initial "start test" system trigger is sent? Ryan R.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.