crossrulz

Here you go. test_vis.zip

When I upgrade the VI, it didn't break. Not sure why Francois would be different. scxi-1122_voltage.zip I must admit, old examples is the only reason I kept 7.1 on my machine.

That is a very good point. I will endure until the kind, wonderful admins of this great forum find the problem.

Yep, my RSS was cleaned out and then *bang* 200 postings, all Alpha String. My RSS will only grab the first 200 from that post so I don't know who to shoot for actually posting to the Alfa String. I think I'm with Ton, complain until it is fixed. That's how it goes around my work too. I don't know how many months I annoyed my boss before finally getting a response about NI Week.

Or if you are looking for a piece of software for screen shots, I highly recommend Snagit

I too have had problems with USB-to-serial adapters. If I remember correctly (I'm going back a few years), the main problem was that each time the adapter was plugged in it had a different COM port or the settings were totally different. I also had to "synchronize" the VISA drivers in MAX to what Windows had occasionally.

For me, it seems to rear it's ugly head daily. If a new post comes in on day 1, I get the entire thread. If someone else posts on the same thread on the same day (after I went through and deleted), only that one post shows up. Next day, new post will cause the entire thread again. Doesn't matter if it is Lava 1.0 or Lava 2.0 threads.

I made this one to find the serial ports available in a system. Get List of Serial Ports.vi

Like the VISA Find Resource

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.

Newton's Cradle anybody?

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.

Assuming I'm understanding your checksum protocol correctly, this should do the trick.