-
Posts
548 -
Joined
-
Last visited
-
Days Won
25
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by crossrulz
-
-
The Remote Instruction Handler is what reads and processes the data being sent to the monitor (from Test Stand or internally) via the Monitor Queue. What we do is for each test step we send the Test Paragraph, Description, Upper Limit, Lower Limit, Measurement, and Pass/Fail via the Monitor Queue to the monitor. The Remote Instruction Handler will then read from that queue and process the data however it needs to (send data to be written to file, update step information, update measurement displays, etc.). The queue is being created in the Monitor Queue.vi when the task is set to Initialize. We have a wait in Test Stand that will sit there and wait for the queue to be created before performing tests (poll the Monitor Queue to see if the ref is still a NULL). This way we know the monitor is up and running and we won't miss commands (which was a lesson learned over the years). But the Remote Instruction Handler is the main part of the Monitor VI.
-
You send data to the monitor using the Monitor Queue.vi. That VI is an action engine. Set the task to Send Message and pass in the string data. The data will then be placed in the queue that the monitor VI will read from. The monitor VI will then decipher the message however you need to. When your test is over, send the "TERM" command to shut down the monitor.
-
Here is a majorly stripped down version of what I have been working on. I tried to leave enough for you to get the idea of what I'm doing. It is written in LV 8.6 and TestStand 4.1 Monitor Example.zip
-
A true engineer would use duct tape!!!
-
I'll try to strip one down for you. It'll take some time to get a chance to work on it though. Hopefully by the morning I'll have something for you.
-
We have a sequence that we run in another thread. The only thing in the sequence is a VI that is used as a GUI (we call it a monitor VI). We communicate with this VI using a queue. Since all of our drivers are written in LabVIEW, we just have our drivers send data over this queue and have VIs for sending specific commands called from the TestStand level. It is not terribly difficult. Just remember to set the sequence to run is a new thread (so that TS won't wait for it to end before moving on) and that the GUI will close upon a terminate command when your testing is done. If you have more specific questions, let me know. I have been recently working on this sort of thing.
-
When the ATE is being developed in parallel with the product, you get the exact same mess as you are talking about. I'm going through that right now. Every other day there is a pin moved, requirement changed, subassembly totally redesigned, protocols changed, etc. Development testing starts and then all of your requirements change again. Needless to say, it is quite frustrating.
-
If all CAN transmits have to go through a single VI, simply make that VI non-reentrant and the semaphores aren't needed. The VI itself will act like a semaphore since it can only run in one thread at a time. I did the same thing with a serial port until I made the realization that they aren't needed due to the non-reentrancy of my serial port control VI. But I seriously wonder what is holding your semaphore.
-
I had the exact same thought. These functions have absolutely nothing to do with placing new nodes on the block diagram. But whatever. There they are. CTL+SPACE and then another CTL combo. RCF makes so much more sense in this matter.
-
VIs are normally known strictly by name. When a VI is added to a library, the library name becomes part of the VI name in memory. For instance, I have a VI called "Initialize.vi" for two different libraries (in my case, N5700 and KE2425). These are for power supplies. The Agilent N5700 and Keithley 2425 need different initialization processes. If I didn't put Initialize.vi into a library, there would be a conflict. So I made the two libraries. Now I have, according the the LV memory space, "N5700.lvlib:Initialize.vi" and "KE2425.lvlib:Initialize.vi". Two different VIs. So I guess the short answer to your question is because the lvlib is part of the VI's name in memory space.
-
If you look in the timing pallet, there is a Date/Time to Seconds which takes in a cluster. Parse out your strings, fill in the clusters, convert and subtract.
-
I keep getting the entirety of a thread whenever someone adds to the topic in my RSS reader. For instance, Jarimatti Valkonen posted to "Lurker Roll Call" on 7/15/09 at 12:15PM. Instead of seeing that one post, I got all 93 posts in the RSS. For small threads, this isn't so bad. But for large ones like this (and Heaven forbid the Alpha String ) it is kind of a pain. I am using Outlook 2007 on Windows XP as my RSS reader.
-
Just quickly thinking about it again (after reading the RSS), the masking (AND) should be done last (after the summing). Sorry for the lapse in logic.
-
My boss still won't make a decision about whether or not I'm going. It'll probably be like last year. "Hey, NI Week starts tomorrow! Who wants to go?" I keep pinging him, so we'll see.
-
-
Yeah, gotta love those highly generic emails. It's an automated message that they send out. Could they sound less arrogant? Probably. But that's marketing for you. I usually just instantly delete e-mails like that and move on.
-
QUOTE (Cat @ May 19 2009, 07:27 AM) It sounds like the episode where they find the silicon life form on that mining planet, at the end when Bones is trying to heal the "mother". Cause then Bones pops up and and says something like "Maybe I am a bricklayer" once he healed the "mother's" phaser injury. I couldn't tell you the episode name, but I remember it being on the first season.
-
You can simply create a VISA indicator and pass the reference out that way. I create chains of VIs to read, write, change baud rate, etc. using the VISA resource reference and the error cluster. Seems to work quite well for me.
-
QUOTE (Gavin Burnell @ May 12 2009, 09:43 AM) Dude, that is hilarious. I just spent the last hour looking at it figuring out what you did. I can tell you wasted a lot of time puting it together. On a side note, this would be an excellent example for a lecture on refactoring.
-
Might I recommend the USB I2C/SPI module from NI (USB-8451). It is very easy to use. I know very little about SPI, but this guy does it all for me.
-
Timed loop bug - could someone please confirm
crossrulz replied to george seifert's topic in LabVIEW Bugs
I ran it all through lunch with no error. I am also using LabVIEW 8.6, so it's not exactly the test you are looking for. -
QUOTE I have had to do this with some computers. Take out the hard drive and make it a secondary hard drive on a newer computer. As long as you don't muck around with what is actually on the hard drive, it should go back into the old computer and run just fine. I am also assuming you have another computer with ATA hard drive connections and not the SATA. This is also a good way of getting into people's "My Documents" :ninja: . My next question though is how was this file generated in the first place? There has to be a VI or something somewhere that was used to generate it. Or if all else fails, make your own new table and change the code to be able to read your new format.