Tracking down a stuttering JAG/CAM drive.
 

I continue to try to get my drive working with encoders/Cam etc.

I currently have a problem in that my drives Stutter as I drive.

By this I mean that when they should be driving smoothly they seem to freeze momentarily on a semi regular basis... eg once a second.

To track this down, I dropped back to a raw Robot Project (LabVIEW) and just switched the Open Drive to a CAN version with ID's 11 and 12 (to match my Jags).

Result.... it rans a smooth as a baby's.... you get the idea.

So I slowly started stripping code out of my own app untill the stutter went away (boy I wish I undserstod the safety code)

Bottom line is very interesting. When I took out the Compressor code, my drive went smooth.

I have replicated the problem with the Basic Robot code. If I open a compressor VI in Begin (and save the ref nin a global) and then in Teleop I just do two calls.... one to read the Compressor status, and one to Stop the Compressor (normally used in response to a compressor on/off switch on the DS)

With these two VIs called once per teleop cycle, my motors go back to stuttering once a second.

How is it possible for these two simple calls to cause this problem? I've attached my simplified test code. Only chanages are to Begin and Teleop.

Re: Tracking down a stuttering JAG/CAM drive.
 

Let me preface this by saying, I don't know the LV WPILib at all. However, C++ the compressor class spawns a new thread to periodically check the pressure swicth. People have complained about this thread's CPU usage in the past. From that thread, it seems like changing the state of the compressor (with your DS switch) is adding burden to the task. Perhaps you should just use a relay VI and a digital input VI (pressure switch) to replace your compressor VI. Just poll the pressure switch in your Teleop/Auto main loops

Also, you should fix your "CAM" typos to "CAN" in the Title and post. People may mistakenly think that you are driving a CAM linkage with a motor on a Jag

Re: Tracking down a stuttering JAG/CAM drive.
 

You could certainly make this much more efficient.
Only call them once and only once each time the DS switch is thrown, not 50 times a second...

In general, don't call things when you don't have to and it'll save you a lot of wasted time and grief.
You will have to call things like your drive motors every time a new driver packet arrives, because those inputs change rapidly.
Other things controlled by a button or switch generally do not have to be called so often. Just when the switch or button changes.

Re: Tracking down a stuttering JAG/CAM drive.
 

The safety code is easy to understand. By default, drive motors will be be shut off if you don't keep setting their value at least every tenth of a second. That's it.

I have two questions about your compressor code. First, why are you storing the compressor reference in a global variable instead of using the refnum registry? Second, why are you reading the compressor status and not doing anything with the result?

Re: Tracking down a stuttering JAG/CAM drive.
 

I haven't looked at the code you posted, but I agree with Mark, I think you will see the problem go away if you only check the compressor state and call Start or Stop one time when the appropriate switch is flipped.

Related posts:
http://www.chiefdelphi.com/forums/sh...91&postcount=4
http://www.chiefdelphi.com/forums/sh...56&postcount=6
http://www.chiefdelphi.com/forums/sh...ght=compressor

Re: Tracking down a stuttering JAG/CAM drive.
 

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.

Re: Tracking down a stuttering JAG/CAM drive.
 

In the sample I posted I took out all the "misc" code that might have had an effect, but didn't. In our real code we are taking the Compressor (pressure) status and sending it to an LED on the Driver Station.

As for why I'm putting the ref in a global, that's how we do all the refs in our code. It was done this way in the first year of FRC LabVIEW, and I've never really taken to the "new" way of storing them in the registry. I don't like the fact that the registry usage can't be checked by the compiler at build time. Any name typos are only detected at run time, and you have to be looking for them. Plus it's not particularly extensible anyway... Every new refnum type needs it's own put/get VI...

I also don't like the way the code has to do the refnum lookup every time the VI is run. I just got hammered for being inefficient in calling the "start" for the compressor every time around the loop. I don't see why I need to incurr the code/time penalty for looking up the refnum each time around the loop either. It just seemed much more direct to read it from a global variable.

Phil.

Re: Tracking down a stuttering JAG/CAM drive.
 

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...:)

Actually the Compressor status call takes just as much time as the Start/Stop vi's, possibly longer since it will wait up to 100ms for the status from the other task before returning. This while it's being called from what's supposed to be a 20ms vi. The Start/Stop vi's return immediately.
I don't think the compressor part is a CPU issue. I think it's a sluggish loop issue. Anything longer then 100ms will trip the Safety vi's, which isn't a bad thing as it's notifying you that there's a timing problem.

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.

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?

Can't comment on your other motor output calls.
Those could be due to other reasons, such as, an unrestrained loop that does make it a CPU drain.

Re: Tracking down a stuttering JAG/CAM drive.
 

Phil. Feel free to drop a laggy version to Doug or myself. We have noticed some usage of WPILib that isn't really what was intended, and need to program them a bit more defensively. Others just need to be sped up.

As Mark mentioned, using either the Elapsed Time VIs or the profiler will help identify the code rates and CPU usage.

Greg McKaskle

Re: Tracking down a stuttering JAG/CAM drive.
 

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?)

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...

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 :)

Re: Tracking down a stuttering JAG/CAM drive.
 

If you're using the default Dashboard, then the response is very slow, because it uses the low priority Set User Data Low.vi

However, there is a high priority vi that gets you your data right away.
That's the one I recommend using for robot/team specific data that you really care about.

It's completely unused in the default dashboard and robot framework in order to set it aside exclusively for team use. It's in the WPI->Driver Station palette.


I never use the compressor status check or any compressor calls outside of Begin.
I like pulling breakers to keep the compressor from running. :)

Re: Tracking down a stuttering JAG/CAM drive.
 

I guess I need to look at this to understand the mechanism.
Our status is being sent to an LED on the Cypress module.
That's done by the DS (not the dashboard... right?)

Can I just speed up that item through the DS, or do I need to send custom data to a custom dashboard and then get it to the Cypress..... I'm so confused...!

Sounds like you got the memo that I missed.
Pulling breakers...... excuse me !!!!!

Re: Tracking down a stuttering JAG/CAM drive.
 

Yea, the Cypress outputs are directed by the DS app.
I was thinking of Dashboard lights.

I haven't looked at the latency of Cypress outputs.
It all comes across in the same packets, but I don't know if they are sliced into every packet or only every nth packet.

Re: Tracking down a stuttering JAG/CAM drive.
 

DS data that includes Cypress info is sent eery packet. The latency could be off by a packet depending on when you are updating things. Also, the high and low priority data really isn't that different. The names refer to what is done when there isn't room for all of the data to fit. The normal case is for all data to be sent each packet. The slow dashboard is due more to the Build Data method of metering out the reads and reporting data twice a second.

Greg McKaskle

Re: Tracking down a stuttering JAG/CAM drive.
 

I forgot how you split up the IO data for the default Dashboard to spread the impact of reading it all out a bit .