Encoder Counter Intermittently Set to 0

[mrjimmy]

I am using Labview on a windows XP box with a 6221 DAQ board connected to a 7330 motion controller via a RTSI bus.  I believe I have everything roughly working, but there is a behavior that I would like to explain before I go live.

I am sampling an analog input in lock step with a counter that is fed by the encoder signal from the motor.  So I have a series of 2 numbers that I record to file, and the sampling starts at the same time, the sampling is done by the same clock.  This all seems to work.

If I look at my series of #s regarding the counted ticks that the counter has generated from the linear encoder task that I set up to keep track of the encoder position, I'll get what I expect, but once in awhile there will be a 0 stuck in there.

For example:

1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
0
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023

I cannot seem to discern when this happens and when it does not.  My first guess is it has to do with motor speed/acceleration and sampling rate of the DAQmx Create Channel T(AI) I used to sample the analog input which is the same sample clock that is used for the DAQmx Create Channel (CI-Position Linear Encoder), but I have not had this behvior be reproducible based on sampling frequency or motor speed.

I appreciate any ideas.

Thanks

[J.Harv]

mrjimmy-

     I can't think of any reason for that behavior off the top of my head except for the things that you mentioned (sampling rate) but you said that didn't seem to make the issue better or worse.  I wanted to get some clarification to help us narrow down the problem...
    OK so as I understand it you are trying to control a stepper motor (based on that's what the 7330 does) and you have it in closed loop (which is why you have an analog and digital signals) and are reading back the analog and digital position data.  Both of which are being read back by the 7330 and then the digital signal from the encoder you are passing via RTSI to the DAQ board and that is where you are reading and recording those values. 
    I guess it would be pretty hard to see if there is a missing pulse looking at the TTL signal on the 7330's user defined digital lines...but what if you wire the siganl directly up to the DAQ board? any change? and in your example the count goes from 12 to 14 and there is the 0 where 13 should be...is this always the case? does it keep the correct count? and is it always at the same number?  Also, does the analog signal have anything to do with the digital signal you are sending to the counter (other than that you want them to have the same sample clock)  Anything we can do to separate which board is causing the issue will be helpful...(so try wiring directly to the daq and see...)  I think I just need a bit more info at this time, so anything else odd or whatever you can think of will be helpful.  Thanks.

John Harvey
Applications Engineer
National Instruments
http://www.ni.com/support

[mrjimmy]

Sorry for the delay, I've been working on other items.

  OK so as I understand it you are trying to control a stepper motor (based on that's what the 7330 does) and you have it in closed loop (which is why you have an analog and digital signals) and are reading back the analog and digital position data. 

Clarification: I am reading the digital position data from the encoder and analog voltage from a force transducer that will vary over the course of the movement (the force will be all over the place during move)

Both of which are being read back by the 7330 and then the digital signal from the encoder you are passing via RTSI to the DAQ board and that is where you are reading and recording those values. 

Further Clarification:  Only the digital encoder signal goes back to 7330 and then is routed over the RTSI. The analog signal goes striaght into the DAQ.
                            Additionally, the digital encoder signal gets routes over RTSI to PFIs 8,10,9 that are counter 0's inputs.  I then set up a DAQmx Create Channel (CI Linear Encoder) event to sample the counter in step with the analog input.

    I guess it would be pretty hard to see if there is a missing pulse looking at the TTL signal on the 7330's user defined digital lines...but what if you wire the siganl directly up to the DAQ board? any change?
Have not tried, and probably won't (I'll explain why I won't try below)

and in your example the count goes from 12 to 14 and there is the 0 where 13 should be...is this always the case? does it keep the correct count? and is it always at the same number? 
       The count doesn't skip #s, it just goes 12 12 12 12 0 12 12 12 13 13 13 14 14 14  (I need to check this behavior more, will do that next week)
       Count is correct
       Not at the same #
       -Since there is no # skipping, or I can just interpolate what 0 should be, I'm hesitant to rewire things.
      
Also, does the analog signal have anything to do with the digital signal you are sending to the counter (other than that you want them to have the same sample clock)
    The signals have nothing to do with each other at this point because I am just debugging the system with a fake input

Seeing that I am sampling a counter, all I can think of is that there is a mismatch somewhere in the counter sampling event.  That is to say, the counter value is always at a value, when it gets latched and how many times it is sampled and how many times I read it out might give some mismatch where I think that I have recorded X events, but because of timing, only X-1 samples have made it into the buffer?  Could it be something like that, that would be my only explaination of why a 0 gets in there, because as I said I am sampling a counter.

Thanks

[J.Harv]

mrjimmy--

     OK, so we have a digital signal coming into the 7330 then being routed (via RTSI) to a DAQ board. Why does it go 12, 12, 12, 12, 13, 13 etc.  In your first post it was recording 1001, 1002, 1003....is that what is being stored into the file after processing?  What are the other numbers?  The counter app should start at 0 or 1 and count up from there.  I think one thing that would help is sending the signal to counter 0's source rather than sending it to the source, gate etc. I'd bet if you only sent it to the source that would help.  If you send it to the gate as well it will only be collecting when the gate is high and although this shouldn't matter too much if the signal goes to the source first then the gate you could be missing data. Also, if you wire the encoder directly to the DAQ board does the problem persist?  I am not suggesting you do this permanently...just as a way to eliminate if it is your signal, the 7330 or the DAQ board and help us troubleshoot what is going on.  Anyway, let me know.

-John H

[mrjimmy]

I sample the counter faster than the motor is moving, so it repeats values depending on the speed of the sampling and the speed of the motor. 


I routed the signals to the counter (A, B, and Index) like it says to for setting up a DAQmx Create Task/Channel (Linear Encoder), and the counter does start at 0 and count up, just like I set it up.

I'm not going to physically splice the wires to get the encoder wires to run directly to the DAQ board because I need to keep it in closed loop mode and the wires that I have right now are not easily spliced.

Thanks

[J.Harv]

mrjimmy--

      I honestly have never seen any behavior like that with the motion cards.  Your position feedback works right? It never skips or jumps and has accurate feedback?  If the position feedback works then if could be something in the way that it's being routed or something with the DAQ card or DAQ programming.  Those are the only options I see. Can you think of anything else?  The reason that I am asking this is that I don't really know much when it gets out of the motion card.  My suggestions are not meant to be answers but rather things that you can do to troubleshoot.  I did not hook up the system and am not there. So am limited in what I can do.  I do not know about what wire you have or not. I am only trying to help.  Could you run the motor in open loop and then wire the encoder to the DAQ card?  Looking at the system as a whole is going to be difficult to see what is happening. We will need to narrow this down.  Start eliminating when and where the signal is correct and not correct.
     There are VI's that come with the motion functions that you could use to read the signal. Make sure the encoder is providing the right information by using the "Read Encoder Position.flx" in the analog/digital palette under motion.  This could help if you see that the system gets out of sync over time, then it is missing on the motion side.
     How are you sending the signal to the RTSI line.  I just want to make sure that you are using the select signals Vi from the motion palette rather than the DAQ route signals.  I mean there are a lot of places this behavior could be happening.  Any additional information could help.  I appreciate you patience, hopefully we'll get this figured out.

Thanks

John H

[mrjimmy]

Well, the thing the strikes me funny about the situation, is that I'm sampling a counter.  I have no idea how this counter is actually made in hardware, but based on my experience, a counter has a value and it stays like that until it wraps over, is incremented, decremented, or reset.  So for a 0 to get in there, I have to think that it is an issue with the task I've created:
that is, 1)either the samples are not stored properly in the buffer or 2)the samples are being read out of the buffer incorrectly. 

I'll have to think about how to try to debug this part, but I guess I could try to seperate the 2 sampling tasks and see if that has anything to do with the 0s ending up in there.  Other than that, I'd have to think of a nifty way to see how often a write or read of the buffer happens and maybe correlate that to my 0s. 

Thanks

[J.Harv]

I agree that is a pretty tough thing to figure out.  Unfortunately, I really dont have too much advice beyond general troubleshooting.  Although, if you have any questions while doing that or just need a bit of advice on one specific part just let me know.  Best of luck

-John H