Quote:
Originally Posted by Mark McLeod
You could certainly make this much more efficient.
|
You are correct... I should have known better.... I should only have changed the start/stop state when the switch changed... Very inefficient. Bad me!
After reading the related posts... That VI should come with a warning lable..... "Do Not call more than 10 times a second!!!!!"
Unfortunately that's not the only problem.
If I comment out the start/stop action and just call the Compressor Status VI (to get the pressure status) it still happens. Surely that one call can't be consuming enough CPU cycles to make a difference. And it doesn't seem tied just to this function. I do some other motor outputs in my 100mS periodic task loop, and this also causes the stutter (tested by putting the output code in a disable block, and the stutter goes away). (BTW, I'm not doing any vision processing, in fact the vision was turned OFF for my testing, no no CPU hogging there)
I can't believe that the baseline code is walking such a fine line. I think I have a bigger problem, but don't know where to start looking. I'm testing on a bare bones system.
Other than pure serial bandwidth, are there other consideration which apply to sending CAN commands to Jags... like not putting motor drive/command VI's in parallel loops because of command collisions.
BTW, how good it the error detection on the Serial CAN interface? Will ALL errors be detected or just some? ie: If the LV code says "no error" can this be trusted 100% or does it just mean that the command was sent, but no guarentee that it was received?
Phil.