Error -200140 PWM on Demand in 2015

[Matt_AM]

Hey Fancy Folk,

Background:

I have a motor that I am controlling and I am getting its position back to me in PWM with a period of 1 ms.  I am not interested in every position, just making sure that the motor is moving.

In MAX, the task I am using is an On Demand timed PWM Read on a 6602 where the PWM signal is going into the gate of ctr 6. 

In the LV code, I am using a read 1 counter N samples (originally it was a buffered signal with an external clock instead of On Demand) with number of samples set to -1.  The read loop has a loop rate of 10 ms.

Problem:

Normally my read loop operates fine, but I am intermittently getting the error code -200140 with my counter read.  Sometimes my code runs for 16 hours, other times its 3 hours.  I have error handling to stop my test when the fault occurred, but everything looked fine (hardware wise) when I'd come back and the test faulted out.

What I think the problem is:

I was searching around the forums and it seemed like the most probable issue is that my signal could be noisy and I am somehow getting the PWM to trigger twice during the On Demand Read.  I am supplying 5V to the motor to generate the PWM and I have tied the 5V PS GND to the 6602's DGND.

My other thought is that I goofed and should have changed the 1 counter N Sample to 1 counter 1 sample when i stopped doing a buffered read.  I figured that reading all available samples for the "On Demand" task would just give me 1 sample and I'd be fine.

My thoughts on Solutions:

I could get a line drive in between the PWM signal and 6602 to clean it up.  I've looked at the motor's PWM signal on an O scope and it looks fine from my observations.

I've already changed by code to 1 counter 1 sample, so I am not sure if that will fix my issue or not, but I figured it wouldn't hurt since it'd be more accurate to what the task is doing.

Any suggestions are welcomed!

Thanks,

Matt

[GerdW]

Hi Matt,

there is so much text, but your code is missing!

Mind to attach it?

[Kevin_Price · Accepted solution]

I'd say that the switch to 1 sample 1 channel is a good move.  I wouldn't be totally confident in the behavior of an attempt to read (possibly) multiple samples from a task that wasn't configured to have a buffer.

But the more pressing matter is that the error you get does indeed sound like some kind of electrical noise or glitch.  I don't expect the change to 1 channel 1 sample will eliminate it. 

You might also want to consider configuring a digital filter on the line used for measuring PWM.   There are DAQmx Channel properties available for enabling and configuring such a filter -- be sure to check the manual because filtering on the 6602 has some quirks in how it behaves as I recall.

-Kevin P

[Kevin_Price · Accepted solution]

Also -- there's also the possibility where you can ignore the occasional -200140 error and try again.  I tend to retry with a For Loop to make it easy to limit the # attempts before giving up and deciding it isn't a "rare" error after all.

Further, on rethinking, I'm not sure I've done unbuffered semi-period measurement under DAQmx, which I think is the method you need to use on a 6602.  I don't think it supports the "Pulse" style counter measurements.

All that to say that a PWM duty cycle measurement would require you to measure 2 intervals, not 1.  So you may need to do a buffered measurement and a 1 Channel N Sample version of Read after all.

-Kevin P

[Matt_AM]

GerdW,

I took an image snippet from my code.  It's nothing crazy LV code wise. 

Below is my init section for the read loop,  I literally start my tasks, put them to a bundle by name and merge all the error lines in a different part of the init loop.  On the block diagram to the right of the init (where you can see the bundle by name) is the read loop which is shown below.

The read loop just reads my tasks and dumps it to the corresponding consumers which either process it or log it.  Nothing too crazy.  One thing to note, to the right of the read loop, I have a property node to set value signaling for my stop button if there is an error stopping the read loop.  This triggers my UI loop's shutdown process which shutdowns the other loops - hence my error handling to shutdown the test.  I probed all the error lines to make sure that the counter read was the one that faulted out (probe 12).  Unsurprisingly, it was and probes 10 and 11 were fine.

Matt

[Matt_AM]

Kevin P,

I forgot about the filtering.  I know I had to use that once for a tower which ran several of these motors.  If I remember correctly, it basically ignores any pulses below a specific length of time.  Thanks for triggering that memory!

As for needing 2 reads, I would 100% agree with you. However, the application these motors are going in to take the high time and divide it by the expected period (1ms).  I was talking with one of the designers and he said that it saves them processing time to assume that the period is always constant so they wont have to also measure off time, just on time.  I figured if it was good enough for them, it'd be good enough for me. 

Matt