Following error monitoring on stepper machines

andypugh wrote:

109jb wrote:

As a start, the link below is to one encoder option that I am looking at. It is advertised as 5V-24V, so hoping it works well on 5V. It is 600 pulses per rev, which is enough for the following error detection I desire

You might need to look at this from the other end. What pulse frequency can your parallel port successfully count at?

Choose the encoders based on this number.

The HAL changes are probably extremely simple, you only really need to connect axis.N.motor-position-fb to the encoder position rather than to the stepgen internally calculated position.

Thanks for the tip. How would I determine how fast the parallel port can count? Can it count as fast as it can send step signals?

OK. Thanks.

Another couple questions.

1. I'm not very knowledgeable about encoders. So when an encoder says something like 400 pulses per revolution and it has A and B channels, does that mean that each channel has 400 pulses and then with the 2 channels you essentially have twice the resolution, so that a 400 P/R encoder can actually resolve 800 divisions per rev if both A and B channels are used?

2. Also, since an encoder has A and B channels I assume that each encoder will need 2 inputs on the parallel port, so for 3 axes I'll need 6 inputs for the 3 encoders. Is this correct?

3. If I do need 6 inputs for the 3 encoders then will I have to have a 2nd parallel port or can the first/single PP be configured with 7 inputs (6 for encoders, 1 for combined limit/home switches)? If I can do this then I would prefer to have just one PP.

4. I'm not totally opposed to having a 2nd parallel port, but if I do have to add one will it affect the latency of the system?

Thanks for the help.

1. A 400 PPR (Pulses Per Revolution) encoder will have 1600 counts per revolution

2. Yes, you need 2 inputs per encoder

3. Pretty sure you only have 2 options on parallel port I/O:
out mode = 12 outputs and 5 inputs (Dx pins are outputs)
in mode = 4 outputs and 13 inputs (Dx pins are inputs)

4. Having a second parallel port will not increase your latency but may limit your base thread rate somewhat
due to the added access time of the second port

X-mode for parallel ports is great (I have 2 machines that use it) except that there isn't an off the shelf breakout board anywhere in the world that supports it. If you need more than one port anyway, using one as IN and one as OUT will give you the same number of input and out put pins as 2 X-mode ports, plus you can use stock breakout boards.

There are stock boards that work with in-mode such as a C10 board.
cnc4pc.com/motion-control/breakout-board...-interface-card.html

If you know of a board that works with X-mode, I would love to hear about it. Post a link please.

Thanks guys. Lots to digest. I finally had a chance to look at my LinuxCNC settings but am not sure if the way I have them now will be any help. When I originally set up the machine I ran the latency test and used the stepper config wizard to set up the machine. As originally set up I would on the rare occasion get a real time warning, so I set the max jitter number as high as possible to still achieve the stepping rate I wanted. I don't remember what the latency tests actually showed, but the max jitter setting is currently at 25000 nS and the step config wizard shows that gets a max step rate of ~34 kHz. I set it this way because I only need to step at 27 kHz anyway and didn't feel that the max jitter had to be on the bleeding edge of what my PC can achieve to do this. So that brings up question #1

1. Does raising the max jitter value reduce the likelihood of experiencing real time warnings? It seems like it has pretty much solved that problem for me, although I did do a few of the other tricks to help real time performance along with raising the jitter value.

As far as the breakout boards, this wasn't something I was thinking of. Unfortunately the one I am using is a cheaper one that has opto's that only allow one direction. So on this one I can only have 12 outputs and 5 inputs because that is the way it is set up. I am only using 7 outputs (Step and Dir on 3 axes + 1 for enable) and 3 inputs (Combined home/limits on 3 axes) right now. For testing this out on just the X-axis, I can use the parallel port board I have right now and a single parallel port since I currently have 2 unused inputs. I can deal with the second parallel port and breakout board for it when needed. When that time comes i could just get by with another cheap breakout board like the one I have now, and just have a bunch of unused pins, but will cross that bridge later.

2. As far as what encoder to choose, I'm looking for suggestions. What I would like to achieve is following error detection of about 0.002" and my setup is such that 1 rev of the motor is 0.2", so I want to detect when the actual position is off by more than 1/100th of a revolution from the commanded position. Based on this, I think a 200 PPR encoder that would have 800 counts per rev should be more than enough for this, and would be less taxing on the system than a higher PPR encoder in terms of reading the encoder pulses. Is this a correct way to think about this or is there a reason to go to higher counts per rev?

Thanks for the help. You guys have been great.