EricLarsen

Yep, that does it. Using the path control's browse button to open a data file on the local drive redirects Labview's file handle away from the USB disk. Then the USB can be ejected. I wonder if there is a work around that can programmatically force Labview to redirect that file handle away from the USB disk. When I get a chance I'll play around and see if I can work something out.

Just out of curiosity, what kinds of filters have you found to be effective for this? I've had this problem before and never really came up with a satisfactory solution.

Most encoders are differential and will be labeled A+, A-, B+, B-. Some encoders are single ended and are usually labeled A, B, and Gnd (or something like that). In that case, you would hook A to A+, B to B+, and Gnd to both A- and B-. If you truly have a single ended encoder, you might check with the manufacturer to see how they recommend hook up. Disclaimer: Hooking single ended encoders into differential inputs doesn't always work and is usually not recommend by the encoder card manufacturer. But I've done it a few times and it's never burst into flames.

Has anyone else run into an issue where Windows won't let you eject a USB flash disk if you've been reading files off of it into Labview? I often use my USB disk to transfer files between the lab and my office for analysis, and a lot of times I'll have to quit Labview before I can eject the disk. It seems that Labview is holding on to a directory handle when maybe it shouldn't be. I was able to see that using Process Explorer. In the first example, I dragged and dropped the file name into the file path control and ran the code. Labview opened up one file handle to the file, and released it when Close File was executed. At this point I could successfully eject the USB disk In the second example, I used the Browse button on the front panel control to select the file. Labivew opened up two handles, one to the file and one to the directory the file was in. When Close File was executed, only the handle to the file itself was closed, the handle to the directory remained open. I was unable to eject the disk until I quit Labview. Anybody seen this before? Is there anyway to force Labview to close the handle to the directory so I can eject the disk? I'm using 2009, but I'm fairly certain I've seen this in earlier versions.

If you were building an EMG to use on dung beetles, I'd say go for it and build one yourself. On human subjects, or even cute and/or edible animals, no way. Like Rolf said, approvals for human trials can take years and cost MANY times what the equipment itself costs. Correct me if I'm wrong, but doesn't EMG involve piercing the skin with electrodes? A leakage current of as little as 5 millamps applied in the wrong spot can kill a person. There was a topic that came up on the info-labview board years ago by a person who was doing EKG measurements on pigs. He'd hook up the EKG leads to the data acquisition box and the pig would die from cardiac arrest. Ground loops can be a real bummer.....

Most of the Oriental Motor controllers I've seen have a serial (RS-232) interface. Check with them, they might have Labview drivers already. If not, check the NI Instrument Driver network. Sometimes you get lucky there. You can also write your own interface code as well, which is a really important Labview skill to learn. You're jumping into the Labview deep end on this project, but I you can make it work it will be a good experience.

Tim has the right idea, you want to create a circular buffer to hold the data. If you know approximately how long the event is, it makes life eaiser. Say you are looking for an event that is 1 second long. Grab data out of the DAQ buffer in 250 ms chunks. Allocate an array of chunks that is 2 seconds long, or 8 chunks. As you grab each new chunk, rotate the array and replace the end element with the new chunk. This has the effect of discarding your oldest chunk. Concatate the array into one continuous waveform and look for your valley. You'll have to tune your chunk size and array length to your application.

Just thinking out loud here, I don't have any hardware in front of me to test this. If you have a regenerating AO happening and you write a new waveform to DaqMX write, doesn't it allow the old waveform to finish generating before starting in on the new waveform? I'm not sure, but I think it does. What if the new waveform was all zeros or some other safe waveform that shut down your equipment? You let that go for a few cycles, and then stop the output. Without knowing the specifics of your application I don't know if that will work, but might be worth a try.

Using a local variable in a Real-Time time critical loop is also much faster and less jittery than a property node. Yes, I know you're not supposed to use either in a time critical node, but let's face it, we're all guilty of that now and again, especially during the development stage.

In 2009 this can also be set from Tools >> Options >> Environment >> Maximum undo steps per VI. Probably a bit safer doing it from here then editing the .ini file.

The scoring for the exam is based on 40 points, 15 for style, 15 for Functionality, and 10 for Documentation. Divide your time up accordingly. Our natural instinct as programmers is to focus on Functionality, which in the case of this exam might hurt you. Documentation is really quite easy and shouldn't take more than a few minutes, so don't miss out on those points. In addition to my previous suggestions, also add descriptions to all your sub-vis. Do this as you create the sub-vis, much eaiser than than trying to go back at the end of the test and add it. For Style, graders are looking for things like unnecessary wire bends, coersion dots, overlapping objects, unused code, stuff like that. My biggest loss of points was due to the fact I didn't handle errors. I'd planned implement an error handing routine at the end, and I ran out of time. If I'd added it from the start I'd probably have gotten a better score. But most of all, just relax. It's really not that hard.

Over all it looks good. Make sure you add descriptions and tip strip documentation to all of the front panel controls on your main vi. You don't need to write a paragraph for each one, just a quick sentence or two. Add some labels on your wires on the block diagram, at least for the main wires. Add a few more diagram labes here and there, clean up a few wire bends, and eliminate the coercion dot on the Car Wash Indicator tunnel. None of that should take too long and will help boost your score. Good luck, and tell us how it went.

I'm not really familiar with the MC3479. It looks like it might be a fairly standard stepper driver, and most of them work about the same way. To answer your questions generally, steppers are fairly simple motors and are easy to control. That's why they are so popular. To keep a motor in a constant position, you 'may' have to keep the current on. It depends on the configuration of the load. A stepper motor will generate no torque without current. But if your load is self locking, such as a horizontal motion or a vertical motion with a high pitch drive screw, it may stay in position. Another option is to use a relay brake that engages when the current is shut off. If your load is too heavy, the motor will stall. A stall in a stepper motor is usually easy to detect just by the sound it makes. Most stepper motor drivers have a stall detect feature, where an encoder is attached to the load and if the encoder doesn't keep up with commanded position, the controller will detect an error. If your load is too heavy, there really isn't much you can do to correct it other than get a bigger motor. Slowing the velocity and acceleration can help some, as can changing gear ratios, but that doesn't always work. Does your application require you to start with an MC3479? There are many manufactures of stepper motor controllers that would save you a lot of time instead of building your own.