Quote:
Originally Posted by Mark McLeod
I didn't mean to hammer you about efficency...
I apologize if it came through that way.
But I'm going to beat you up some more...  |
No problems... I've done my fair share of hammering
Based on what I now know about the Compressor VI's I'm going with what I decided last time I tried to use them..... DON'T.
There is obviously a lot of pain buit into those puppies all just to monitor one digital input, and control a relay output.
We were in a rush this year, and just decided to use them, but they have bitten us again. The other thing that is annoying is that when the compressor is Stopped, they no longer give a valid pressure reading (the description of that "Status is pretty vague). So if you turn off the compressor, you can't tell when you've lost pressure...
I'm going back to a simple DigIN poll in Periodic tasks. I don't think the current VI's lend themselves to teams that want to turn the compressor off from the Driver Station (are we the only ones that do that for testing?)
Quote:
You can probably move that LED to a slower periodic check. A quarter second is probably unnoticable to the driver.
If you want to get rid of the refnum altogether, even the use of global overhead, you can put the whole kit and kaboodle into Periodic Tasks.
|
The update to the driver station is already pretty slow. 1/4 Sec would make it worse, but you are essentially correct. We also feed back whether the compressor is "Enabled" (with a second LED) If this one lags the switch too much the drivers start clicking it multiple times...
Quote:
Have you analyzed the CPU usage with the System Manager to help isolate the CPU hogs?
Have you tried using the Elapsed Time vi under Project Manager->Support Code to identify the loop piglets?
|
No. Since I'm already trying to learn how the encoders/Jags work, I didn't want to ALSO be learning how to use those tools. It's unfortunate that when I need them the most, I am already in the thick of confusion. Maybe later when I don't actually need them