Following error monitoring on stepper machines
22 Jan 2017 22:35 #86439
by andypugh
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.
Replied by andypugh on topic Following error monitoring on stepper machines
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.
Please Log in or Create an account to join the conversation.
24 Jan 2017 16:39 #86569
by 109jb
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?
Replied by 109jb on topic Following error monitoring on stepper machines
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?
Please Log in or Create an account to join the conversation.
24 Jan 2017 16:48 #86570
by andypugh
Approximately as fast, yes.
You should know the base-thread rate of your setup, and the maximum counting rate is a simple calculation from that.
Replied by andypugh on topic Following error monitoring on stepper machines
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?
Approximately as fast, yes.
You should know the base-thread rate of your setup, and the maximum counting rate is a simple calculation from that.
Please Log in or Create an account to join the conversation.
25 Jan 2017 00:22 #86586
by 109jb
Replied by 109jb on topic Following error monitoring on stepper machines
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.
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.
Please Log in or Create an account to join the conversation.
25 Jan 2017 01:19 - 25 Jan 2017 01:25 #86587
by PCW
Replied by PCW on topic Following error monitoring on stepper machines
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
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
Last edit: 25 Jan 2017 01:25 by PCW.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 18515
- Thank you received: 6184
25 Jan 2017 11:38 #86606
by tommylight
Replied by tommylight on topic Following error monitoring on stepper machines
There is also mode X for parallel ports, but some do not support that.
All the ports i have do support it. That will do 8 out/9 in pins on it.
All the ports i have do support it. That will do 8 out/9 in pins on it.
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 4978
- Thank you received: 1377
25 Jan 2017 14:01 #86621
by Todd Zuercher
Replied by Todd Zuercher on topic Following error monitoring on stepper machines
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.
Please Log in or Create an account to join the conversation.
- tommylight
-
- Away
- Moderator
-
Less
More
- Posts: 18515
- Thank you received: 6184
25 Jan 2017 14:41 #86626
by tommylight
Nope, stock break out boards will not work with IN mode, or X mode. They use opto couplers and they are one direction only.
I have a much more expensive BOB that can do IN and OUT on all DATA pins as it uses TWO WAY buffers.
Replied by tommylight on topic Following error monitoring on stepper machines
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.
Nope, stock break out boards will not work with IN mode, or X mode. They use opto couplers and they are one direction only.
I have a much more expensive BOB that can do IN and OUT on all DATA pins as it uses TWO WAY buffers.
Please Log in or Create an account to join the conversation.
- Todd Zuercher
-
- Away
- Platinum Member
-
Less
More
- Posts: 4978
- Thank you received: 1377
25 Jan 2017 15:39 #86634
by Todd Zuercher
Replied by Todd Zuercher on topic Following error monitoring on stepper machines
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.
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.
Please Log in or Create an account to join the conversation.
25 Jan 2017 18:02 #86646
by 109jb
Replied by 109jb on topic Following error monitoring on stepper machines
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.
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.
Please Log in or Create an account to join the conversation.
Time to create page: 0.421 seconds