Analogue, yes. Optical is not normally used for such devices but presumably can be. I do know new model rotary encoders have had programmable resolutions for quite some years now.
I think they are usually LVDT devices. Rotary ones, when not converted internally, are called resolvers and usually a single pole so there is one pair of quadrature phase rotations per rotation of the shaft so can be treated like an absolute encoder. Linear ones often have hundreds of poles on a magnetic strip over any length at all but do require calibrating if high accuracy is desired.
EDIT: Oh, I hadn't considered customising the encoder itself. Intriguing idea there Erna. There is an added modulation, there would have to be careful thought put into the quadrant transition so as to obey the correct phase order for quadrature counting.
Relatedly, software can quite effectively use filtering for smoothing of a coarse encoder. It doesn't increase accuracy but does give a nice resolution boost for smooth speed control.
This would require some analog on the front end to resolve the sub-bit position, wouldn't it? Then, it would pwm, so to speak, the sub-bit position, so that the encoder could sum it up and gain another N bits of resolution. The normal count would start at bit N of the numerical output, and bits below N would be the fractional step. That would be pretty neat. The AB encoder would need to track time, not just state.
Yes and No. To prevent oscillation, QEncoders are normally equipped with schmitt-triggers. If oscillation can be controlled, a QDecoder will work properly. But I think, we could make an sensor, where the photodetector is illuminated by two leds and the parallax from different emitter positions leds to the pwm.
I'm wrong, I have seen analogue encoders in the wild before. It was old equipment though.
The schmitt-trigger circuit in encoders is usually built from op-amps anyway, so the analogue encoders just have the op-amps configured for ordinary amplification instead of the schmitt-trigger. You need shielded cables but then it's up to the equipment to derive whatever resolution it can from the sinusoidal quadrature channels.
Analog encoders pass sin/cos currents/voltages. That means, information transfer is extremely critical. I propose the analog/PWM convertion on sensor side. The point is, as already mentioned, the quadrature signal due to existance of forbidden transitions filters spikes automatically. In an optical sensor (and this is true for every transition) the low to high transition itself is always analogue and there are efforts in place to create a digital signal.
Sine wave is no more critical than square wave. The resolution of the pulses is still the same as the line count of the disc. Just that there is potential for further resolution increase beyond that. Whether sine or square, the signals are always shielded twisted pairs using differential signalling in such equipment, so the quality is very high from the outset.
Actually, I wouldn't know if that equipment was really doing anything beyond pulse counting to be honest. I just remember the encoders produced sine waves is all.
000 = no filtering
001 = divide by 1 filtering
010 = divide by 4 filtering
011 = divide by 16 filtering
100 = divide by 64 filtering
101 = divide by 256 filtering
110 = divide by 512 filtering
111 = divide by 1024 filtering
That's close, but I would include /2 as this sets fMax for counters & tMin for capture.
What is /1?
I have an idea for /1 that would use opposite edge clocked ff at the pin.
Filtering is then std 2-vote but half sysclk spaced for net /1 filtering.
ie anything smaller than a half period is rejected, bu you can Frequency count to SysCLK/2 (same as P1)
This also does not impact UART maximums.
That 2f filter cell could then clock select, if lower (wider time) sampling is needed.
Not sure you need all those taps in every PinCell.
A means to tap-into a pin-sampling clk may be enough ?
Imagine to have a quadrature sensor, that doesn't just give states, but is able to create an micro stepping count signal.
Some system now do give micro-step type outputs, but a little differently in the details.
There are some blindspots/caveats in what you describe.
At highest speeds, you lose edge resolution, and at lowest speed the information is in the edges, which are now a long way apart, but also in those edges is the system velocity.
Also, micro-stepping infers usable information between the original steps, but Phase encode only reveals that info every 3 edges.
The more common approach, is to generate a higher frequency Quad-Signal, from the slower one - effectively frequency multiplied.
P2 should be able to do this too, with some SW frequency scaling
Not sure if TWO NCO outputs can be phase-tracked, or one NCO feed to a Gray Counter ?
Anyone see how to get NCO-Quad out ?
On the general broad idea of Phase-encoded phantom signaling in Quadrature, that could have some uses, and would be a good P2 test & demo example.
I can see Index Pulse, or Buttons / ID could encode this way.
It needs 3 edges to decide Phase & P2 pins would need to be able to measure Time Interval A-B (any edge to any edge)
However, I think that rather useful Time Interval A-B (any edge to any edge)
is currently missing from P2 modes ?
Hard to be understood. The moment you are Heidenhain, you have everything you can imagine and it becomes hard to reduce to the min. But we aren't. So we can print a slotted ring on a transparent and use this together with photosensors. Normaly you have two detectors and one to two sensors. Arrangement to the left. But you could also have one detector and two LED's to have a virtual displacement. That also will give a time multiplexed signal. Now combine those two methods and you are able to determine position interpolated what allows for higher resolution from a low resolution grid. Homemade. You even can use old spaghetties. But whenever you talk about motor control please realize: the force available decreases at higher speed and so your ability to accelerate. And therefor you can not correct an error, you detect. For this reason, high resolution at high speed is just unnecessary. But at low speed, close to stand still, every small, unexpected force leads to speed and displacement and to bring down this speed and invert the displacement high resolution in position and speed is needed. The main goal has to be: determine speed at standstill! You are not able to reconstruct speed from a position signal, if the position signal doesn't change. BUT you have a speed information in the sensor befor you destroy this info to determine the position.
I have an idea for /1 that would use opposite edge clocked ff at the pin.
Filtering is then std 2-vote but half sysclk spaced for net /1 filtering.
ie anything smaller than a half period is rejected, bu you can Frequency count to SysCLK/2 (same as P1)
This also does not impact UART maximums.
That 2f filter cell could then clock select, if lower (wider time) sampling is needed.
Looking more into the details, I think this 2f Filter can be done in 3 FF : D_CLK, D_!CLK and a JK_CLK acting on 11 and 00 votes. (two AND gates)
Filter Output is SysCLK _/= sync'd, and needs two samples to change, with a delay of 1.5~2.0 SysCLKs
Hard to be understood. The moment you are Heidenhain, you have everything you can imagine and it becomes hard to reduce to the min. But we aren't. So we can print a slotted ring on a transparent and use this together with photosensors. Normaly you have two detectors and one to two sensors. Arrangement to the left. But you could also have one detector and two LED's to have a virtual displacement. That also will give a time multiplexed signal. Now combine those two methods and you are able to determine position interpolated what allows for higher resolution from a low resolution grid. Homemade. You even can use old spaghetties. But whenever you talk about motor control please realize: the force available decreases at higher speed and so your ability to accelerate. And therefor you can not correct an error, you detect. For this reason, high resolution at high speed is just unnecessary. But at low speed, close to stand still, every small, unexpected force leads to speed and displacement and to bring down this speed and invert the displacement high resolution in position and speed is needed. The main goal has to be: determine speed at standstill! You are not able to reconstruct speed from a position signal, if the position signal doesn't change. BUT you have a speed information in the sensor befor you destroy this info to determine the position.
If a custom component could be made to have the LED on one side and two sensors on the other, that might facilitate the whole thing. Might it be sensitive to solid/open ratios on the rotating piece? It might have dead spots, or non-linearities.
Yes, whenever you share components, you have to make a compromize. In a real encoder, there are two grates, one fixed and two moving, normally only on light source followed by a condensor to spread the light over the sensing area. So the light can pass many slots in parallel resulting in a stronger signal. But: the main point here is: you can move the measuring position without mechanical movement, therefor this can be done in arbitrary speed. For example like the P1 ADC. If you pwm inversely the LED's, the photo transistors signal can be kept constant. Now, like in the P1, where you relatively count the negativ compensation pulses, here you now from counting, how often one of the diodes was fired, where exactly the slots are placed. Certainly, you need to get what you want the adequate precision in manufacturing.
Anyway: if you reread some of the requirements in this thread and match, under which circumstances a given precision in measurement is reached and what action can take place, in resolution of current (force), current delayed by inductance, .. control loop runtime, filter constants, you can easily see: in one area you have to much, in the other not sufficient information.
...
i guess this means allow the smart pins to send data to the smart pins without going hub....just to the pins next to them....
two pins could take the quad encoder....send information to the pins next to them...they can compare and pwn out with direction. no cogs. these pins need to be used anyway...
You can cross link Smart Pin cells now, to a limited degree.
What would be impractical & consume a lot of logic, is a wide data-path link between pins.
Single boolean values, can link in come cases, but any ALU tasks are best done in a COG. (There are 16 COGs)
If you wanted a DONE signal - eg for Quad Generator to Stepper out on two pins, and then a 3rd pin-cell counts those steps, and gives a set point output action, that is probably possible 'in the pins'.
i believe you have pwm output happening in the smartpins
it sounds like you have quad encoder happening in the smart pins
this is great but its been on the drawing board and it really is first step thinking....
my opinion of second step thinking
chip you asked what the next level would be.
get two sets of them smart pins creating a decision without tying up a cog
1as input 1 as output....another layer of parallel computing
this is symetrical....i think we like symetrical
i guess this means allow the smart pins to send data to the smart pins without going hub....just to the pins next to them....
two pins could take the quad encoder....send information to the pins next to them...they can compare and pwn out with direction. no cogs. these pins need to be used anyway...
It seems to me that you may need no less than a PID loop between the quadrature encoder and the PWM. What can be done that is within the scope of simple logic?
i believe you have pwm output happening in the smartpins
it sounds like you have quad encoder happening in the smart pins
this is great but its been on the drawing board and it really is first step thinking....
my opinion of second step thinking
chip you asked what the next level would be.
get two sets of them smart pins creating a decision without tying up a cog
1as input 1 as output....another layer of parallel computing
this is symetrical....i think we like symetrical
i guess this means allow the smart pins to send data to the smart pins without going hub....just to the pins next to them....
two pins could take the quad encoder....send information to the pins next to them...they can compare and pwn out with direction. no cogs. these pins need to be used anyway...
It seems to me that you may need no less than a PID loop between the quadrature encoder and the PWM. What can be done that is within the scope of simple logic?
IIRC, it was @briskmover who stated that he was performing motion control WITHOUT PID(!?!?!?). His post was very cryptic and then he disappeared from the discussion.
What can be done that is within the scope of simple logic?
Things like handshake for UART and FIFO can be done with simple logic, but those may already be there ?
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
What can be done that is within the scope of simple logic?
Things like handshake for UART and FIFO can be done with simple logic, but those may already be there ?
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
What can be done that is within the scope of simple logic?
Things like handshake for UART and FIFO can be done with simple logic, but those may already be there ?
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
We have no hardware handshaking right now.
Do you think it's needed?
The fastest USB interfaces are parallel, using a FIFO model. (ie with handshake)
The streamer is a natural to manage the data speeds, but it is hard to see how that can work as an overall system without hardware handshake.
As well as FIFO modes, for fewer pins and next-fastest FTDI also have Fast Serial Mode, which can go to 50MHz, but that also has a handshake.
See the other thread - the newest serial port design should allow testing that Fast Serial Mode to 40MHz with software handshake, and that will give some numbers on the turnaround delays involved in SW handshake.
A true resolver is dynamic in nature in that the resolution it can report is only as good as the equipment you are using to look at it. That said, at higher speeds, it is not as important to keep track of the fine resolution as much as it is the coarse resolution. Micro positioning only needs to apply during slow and/or a pinpoint stop location, in which case since you are traveling slower you can dynamically "dial in" to the finer resolution based on the equipment looking at the signal. Awhile back I did some testing with a resolver used on an industrial CNC to help a friend of mine whom makes repairs and designs such machines.
In the Resolver Test #1 video, a square wave from the Propeller drives a "primary" coil or "excite" coil on the resolver at a resonant frequency determined by a capacitor in parallel with the resolver "primary" coil.
Two secondary coils on the resolver arranged 90 Deg out of phase within the resolver provide the sine/cosine output. Both coils are also tuned to the same resonant frequency as the primary coil by way of a parallel capacitor placed across each coil. One of the secondary coils along with the excite signal from the propeller are shown on the Resolver Test #1 video.
In the Resolver Test #2 video, both secondary coils are shown as the resolver shaft is rotated by hand.
In the Resolver Test #3 video, an ADC needs to read both sine and cosine signals simultaneously in order to get accurate results. I modified the ADC object to read multiple IC's simultaneously using the same clock and individual data lines. I used two MCP3204 because eventually I needed X,Y, and Z. Since the Propeller is also controlling the excite pulse, I know exactly when to read the ADC at the peak of the sine wave. The coordic routine is applied in software to the ADC results to determine the proper Deg position to display. Output is exceptionally stable.
I'll point out again, that when the shaft is rotating rapidly using a resolver, you only need to look at the coarse position readings, it is only important to look at the fine position readings when moving slow and coming to a pinpoint stop location. Your software should control the trapezoidal ramp up and ramp down speed control and position counting.
Resolver Test #1 video = www.youtube.com/watch?v=X5svWfa6u04
Resolver Test #2 video = www.youtube.com/watch?v=-Rga4V77kLc
Resolver Test #3 video = www.youtube.com/watch?v=gh1rsBDZajo
What can be done that is within the scope of simple logic?
Things like handshake for UART and FIFO can be done with simple logic, but those may already be there ?
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
We have no hardware handshaking right now.
Do you think it's needed?
No! What we need is a finished product! Don't make me have to get Ken involved! 'Cuz I will!
What can be done that is within the scope of simple logic?
Things like handshake for UART and FIFO can be done with simple logic, but those may already be there ?
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
We have no hardware handshaking right now.
Do you think it's needed?
The fastest USB interfaces are parallel, using a FIFO model. (ie with handshake)
The streamer is a natural to manage the data speeds, but it is hard to see how that can work as an overall system without hardware handshake.
As well as FIFO modes, for fewer pins and next-fastest FTDI also have Fast Serial Mode, which can go to 50MHz, but that also has a handshake.
See the other thread - the newest serial port design should allow testing that Fast Serial Mode to 40MHz with software handshake, and that will give some numbers on the turnaround delays involved in SW handshake.
A true resolver is dynamic in nature in that the resolution it can report is only as good as the equipment you are using to look at it. That said, at higher speeds, it is not as important to keep track of the fine resolution as much as it is the coarse resolution. Micro positioning only needs to apply during slow and/or a pinpoint stop location, in which case since you are traveling slower you can dynamically "dial in" to the finer resolution based on the equipment looking at the signal. Awhile back I did some testing with a resolver used on an industrial CNC to help a friend of mine whom makes repairs and designs such machines.
In the Resolver Test #1 video, a square wave from the Propeller drives a "primary" coil or "excite" coil on the resolver at a resonant frequency determined by a capacitor in parallel with the resolver "primary" coil.
Two secondary coils on the resolver arranged 90 Deg out of phase within the resolver provide the sine/cosine output. Both coils are also tuned to the same resonant frequency as the primary coil by way of a parallel capacitor placed across each coil. One of the secondary coils along with the excite signal from the propeller are shown on the Resolver Test #1 video.
In the Resolver Test #2 video, both secondary coils are shown as the resolver shaft is rotated by hand.
In the Resolver Test #3 video, an ADC needs to read both sine and cosine signals simultaneously in order to get accurate results. I modified the ADC object to read multiple IC's simultaneously using the same clock and individual data lines. I used two MCP3204 because eventually I needed X,Y, and Z. Since the Propeller is also controlling the excite pulse, I know exactly when to read the ADC at the peak of the sine wave. The coordic routine is applied in software to the ADC results to determine the proper Deg position to display. Output is exceptionally stable.
I'll point out again, that when the shaft is rotating rapidly using a resolver, you only need to look at the coarse position readings, it is only important to look at the fine position readings when moving slow and coming to a pinpoint stop location. Your software should control the trapezoidal ramp up and ramp down speed control and position counting.
Resolver Test #1 video = www.youtube.com/watch?v=X5svWfa6u04
Resolver Test #2 video = www.youtube.com/watch?v=-Rga4V77kLc
Resolver Test #3 video = www.youtube.com/watch?v=gh1rsBDZajo
Interesting, Beau. That third video makes a complete picture.
What can be done that is within the scope of simple logic?
Things like handshake for UART and FIFO can be done with simple logic, but those may already be there ?
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
We have no hardware handshaking right now.
Do you think it's needed?
No! What we need is a finished product! Don't make me have to get Ken involved! 'Cuz I will!
+1: we need silicon. The rest comes later. Like making use of quadrature encoders: Beau is right. resolution is only important at low speed. Imagine a motor that spins up in one second to 6000/minute == 100/sec. Let us have 10,000 increments of resolution, then this means 1 million increments/sec. Let' assume (what is best case, not real) acceleration is constant, then average speed is 50/s and it took 50 rotations to gain this speed. That also means, the motor accelerates at 1 million increments /sec. At 100/s the duration of one rotation is 10 ms. During this time speed can change by 1% or 100 increments. If now the control loop runs at 10 KHz it means, during on control cycle the number of increments from the encoder can only be changed by 1! But 1 also means uncertainty in digital measurement. Now, what happens if speed deviates by 1 count per control cycle? Within 1 rotation the error sums up to 100 increment. That corresponds to 3.6°. From this follows: at high speed high resolution is not needed, because very small errors in speed within very short time result in large errors in position which can be detected easily.
+1: we need silicon. The details come out later. Every project that makes use of the unique features of the propeller will NEVER fail due to the fact, that a feature is not available that can be realized by other controllers, because for little money such a processor can be a companion and overcome those hurdles.
+1: we need silicon. The rest comes later. Like making use of quadrature encoders: Beau is right. resolution is only important at low speed. Imagine a motor that spins up in one second to 6000/minute == 100/sec. Let us have 10,000 increments of resolution, then this means 1 million increments/sec. Let' assume (what is best case, not real) acceleration is constant, then average speed is 50/s and it took 50 rotations to gain this speed. That also means, the motor accelerates at 1 million increments /sec. At 100/s the duration of one rotation is 10 ms. During this time speed can change by 1% or 100 increments. If now the control loop runs at 10 KHz it means, during on control cycle the number of increments from the encoder can only be changed by 1! But 1 also means uncertainty in digital measurement. Now, what happens if speed deviates by 1 count per control cycle? Within 1 rotation the error sums up to 100 increment. That corresponds to 3.6°. From this follows: at high speed high resolution is not needed, because very small errors in speed within very short time result in large errors in position which can be detected easily.
+1: we need silicon. The details come out later. Every project that makes use of the unique features of the propeller will NEVER fail due to the fact, that a feature is not available that can be realized by other controllers, because for little money such a processor can be a companion and overcome those hurdles.
Agreed, I want to get this done so that we can move onto software.
I did get the 3-of-3 filtering added with selectable 1/8/64/512-clock sub-sampling, as someone provided a link to a while back.
+1: we need silicon. The details come out later. Every project that makes use of the unique features of the propeller will NEVER fail due to the fact, that a feature is not available that can be realized by other controllers, because for little money such a processor can be a companion and overcome those hurdles.
Not quite - The specific question was around Handshake, which is a little different
Handshake is what is needed to make a feature already in P2, work properly in the field.
It is a real-world interaction requirement, that cannot be solved by 'adding another chip',
Instead, it is a (simple) feature required to talk to another chip.
The NCO Clocked nature of P2 links means there is already a Clock Enable, most handshakes simply adds an external pin optionally into that Clock Enable.
I haven't seen anyone even propose a solution for the kinematics issue. We have implementations to make lines and circles using Bresenham's algorithms, but this doesn't get you a correct feedrate in an arc, or on an angle. It requires hard coding the factor for screw lead and gear ratios or belt pitch to even get accurate movement at any speed.
A correct implementation will calculate the points along an arc, or angle, or even a straight line at the correct rate, and then the kinematics engines for each axis go to work to get the motor position targets, It would be VERY sweet to be able to just throw an equation that models the axis' motion, and a position target at an instance of the the kinematics engine, and get back a specific motor's target.
What if your motion axes aren't X,Y,Z? Just calculating real time X,Y,Z position and orientation targets for all the axes in something like a 6 axis robot is massive. The throughput of the CORDIC solver is what will determine the accuracy in terms of number of points per unit travel at a given rate. I have high hopes though, because several cogs can load the CORDIC at virtually the same time.
After all this work is done, we worry about keeping the motors on target. Of course, this must be very fast, or we increase 'following' error by too much. It's really a massive undertaking to get it right!
G code interpreter running yet? No, but really anticipating what may be done when I have a P2 on a board!....
Personally, I think that G-Code or M-Code should be implemented in SOFTWARE within the Propeller or micro of your choosing. The Propeller I does a lot, and the Propeller II will do a lot more. But leave the G-Code and M-Code to live in software, not hardware.
The Pythagorean Theorem can be used in 3D just as easily as most of us are taught to use it in 2D to calculate the distance between any two points in a 3D space.
3D Pythagorean Theorem:
(x1-x2)^2 + (y1-y2)^2 + (z1-z2)^2 = distance^2
Other measurement calculations are trivial, such as RATE, unit conversion, etc.
This gives rate in inches per min:
RATE = RPM/TPI = R/M / T/I = R/M * I/T
These are only BYTE wide conversions, but could easily be expanded to 16,24, or 32 bit operations
In PIC assembly language to convert inches to mm with a multiply function: (1 = 1mm ; 10 = 1 inch)
movf inch,w
addwf inch,w
addwf inch,w
mullw d'218'
movff PRODH,mm
In PIC assembly language to convert mm to inches with a multiply function: (1 = 1mm ; 10 = 1 inch)
movf mm,w
mullw d'101'
movff PRODH,mm
A similar method can be used to determine RPM based on the desired RATE and TPI (Threads Per Inch)
Suppose we need to normalize the RATE and the design engineers really wanted to jack with us an we have a different lead screw pitch on all 3-Axis:
X = 25.4 TPI
Y = 10 TPI
Z = 12.7 TPI
...to further complicate things, suppose we want to specify the RATE in (mm/m) rather than (inch/m) ... actually it's a bit easier in mm/m ... if you want inch/mm ... apply the "inch to mm" routine above prior to applying the RPM calculation below.
RPM = (RATE * TPI ) / 25.4
In PIC assembly language for the 'X Axis':
movf RATE,w
mullw d'255'
movf PRODH,w
addlw d'1'
movwf RPM_X
In PIC assembly language for the 'Y Axis':
movf RATE,w
mullw d'100'
movf PRODH,w
addlw d'1'
movwf RPM_Y
In PIC assembly language for the 'Z Axis':
movf RATE,w
mullw d'127'
movf PRODH,w
addlw d'1'
movwf RPM_Z
...The result is that now you have three different RPM's ( RPM_X, RPM_Y, RPM_Z ) you need to drive your Stepper, or Servo motor at that will produce a consistent "Feed Rate" on all Three Axis
Another derivative of "INTEGER division by way of Multiplying" as used in the above examples, you can calculate the necessary Period requirement based on the RPM values above and the number of steps it takes to complete ONE revolution on your Stepper, or Servo motor.
Again, most of the math is trivial, but with a little mental elbow grease and a big dry erase board it's not that much to tackle.
continuation of a second step on quad encoder.....when using a quad encoder....even if you use a pid algorithm in a cog.....u need to compare the present encoder count to another number.....this can take time on three to 8 axis....this affects resolution.
Because you can clip-onto nearby pins, I think this would already be supported ?
If Generating QUAD, (aka stepper) you would use 2 x NCO with Phase preset, to do any-Fo-Quad, and that can be feeding an adjacent Quad-Counter, preset to some set-point.
If Reading-Quad, you can have two counters in two pin cells, one Absolute version, and another that is your set-point/way-point difference, if you wanted that.
I think Prop can low power wait, on that way-point counter MSB.
Absolutely agree that G code must be implemented in software.
Your calculations and examples are spot on, but fall a bit short of what I understand is needed.
For example, Feed Override. Not a problem your way, if it doesn't change during the cut. Then, what about a manual pulse generator? Even antiques like the Allen Bradley 7370 implement these. As well as not-so-antique Mach 3 and LinuxCNC.
You could change the 'master clock' rate that hopefully all the axes are geared to, but staying on a path, especially an arc, with the ratios locked like that would get hairy fast.
To meet these conditions, You're back to calculating each point on the path, varying the rate of motion of the target position according to the MPG or override, with acceleration, and then letting the motion routines go to work trying to hit the moving target position. (This info also very handy for real-time path display..)
Again, I agree that Prop2 will be up to it!
Again, I find myself reflecting on the amazing job the Engineers of those old CNCs did with what they had. DC servomotors with massive armatures (by today's standards), controlled by SCR amplifiers with maximum 180 hz bandwidth... Amazing that it worked at all, More so with amazing precision, and that some of them are still doing competitive work...
Comments
I think they are usually LVDT devices. Rotary ones, when not converted internally, are called resolvers and usually a single pole so there is one pair of quadrature phase rotations per rotation of the shaft so can be treated like an absolute encoder. Linear ones often have hundreds of poles on a magnetic strip over any length at all but do require calibrating if high accuracy is desired.
EDIT: Oh, I hadn't considered customising the encoder itself. Intriguing idea there Erna. There is an added modulation, there would have to be careful thought put into the quadrant transition so as to obey the correct phase order for quadrature counting.
The schmitt-trigger circuit in encoders is usually built from op-amps anyway, so the analogue encoders just have the op-amps configured for ordinary amplification instead of the schmitt-trigger. You need shielded cables but then it's up to the equipment to derive whatever resolution it can from the sinusoidal quadrature channels.
Actually, I wouldn't know if that equipment was really doing anything beyond pulse counting to be honest. I just remember the encoders produced sine waves is all.
That's close, but I would include /2 as this sets fMax for counters & tMin for capture.
What is /1?
I have an idea for /1 that would use opposite edge clocked ff at the pin.
Filtering is then std 2-vote but half sysclk spaced for net /1 filtering.
ie anything smaller than a half period is rejected, bu you can Frequency count to SysCLK/2 (same as P1)
This also does not impact UART maximums.
That 2f filter cell could then clock select, if lower (wider time) sampling is needed.
Not sure you need all those taps in every PinCell.
A means to tap-into a pin-sampling clk may be enough ?
There are some blindspots/caveats in what you describe.
At highest speeds, you lose edge resolution, and at lowest speed the information is in the edges, which are now a long way apart, but also in those edges is the system velocity.
Also, micro-stepping infers usable information between the original steps, but Phase encode only reveals that info every 3 edges.
The more common approach, is to generate a higher frequency Quad-Signal, from the slower one - effectively frequency multiplied.
P2 should be able to do this too, with some SW frequency scaling
Not sure if TWO NCO outputs can be phase-tracked, or one NCO feed to a Gray Counter ?
Anyone see how to get NCO-Quad out ?
On the general broad idea of Phase-encoded phantom signaling in Quadrature, that could have some uses, and would be a good P2 test & demo example.
I can see Index Pulse, or Buttons / ID could encode this way.
It needs 3 edges to decide Phase & P2 pins would need to be able to measure Time Interval A-B (any edge to any edge)
However, I think that rather useful
Time Interval A-B (any edge to any edge)
is currently missing from P2 modes ?
Hard to be understood. The moment you are Heidenhain, you have everything you can imagine and it becomes hard to reduce to the min. But we aren't. So we can print a slotted ring on a transparent and use this together with photosensors. Normaly you have two detectors and one to two sensors. Arrangement to the left. But you could also have one detector and two LED's to have a virtual displacement. That also will give a time multiplexed signal. Now combine those two methods and you are able to determine position interpolated what allows for higher resolution from a low resolution grid. Homemade. You even can use old spaghetties. But whenever you talk about motor control please realize: the force available decreases at higher speed and so your ability to accelerate. And therefor you can not correct an error, you detect. For this reason, high resolution at high speed is just unnecessary. But at low speed, close to stand still, every small, unexpected force leads to speed and displacement and to bring down this speed and invert the displacement high resolution in position and speed is needed. The main goal has to be: determine speed at standstill! You are not able to reconstruct speed from a position signal, if the position signal doesn't change. BUT you have a speed information in the sensor befor you destroy this info to determine the position.
Filter Output is SysCLK _/= sync'd, and needs two samples to change, with a delay of 1.5~2.0 SysCLKs
If a custom component could be made to have the LED on one side and two sensors on the other, that might facilitate the whole thing. Might it be sensitive to solid/open ratios on the rotating piece? It might have dead spots, or non-linearities.
Anyway: if you reread some of the requirements in this thread and match, under which circumstances a given precision in measurement is reached and what action can take place, in resolution of current (force), current delayed by inductance, .. control loop runtime, filter constants, you can easily see: in one area you have to much, in the other not sufficient information.
The screenshot can also be seen, as work in progress here: https://submesh.de:8080/rid=1PX7QH4WZ-BYFGG4-FZZ/Quadrature%20encode%20incremental%20encoder.cmap
What would be impractical & consume a lot of logic, is a wide data-path link between pins.
Single boolean values, can link in come cases, but any ALU tasks are best done in a COG. (There are 16 COGs)
If you wanted a DONE signal - eg for Quad Generator to Stepper out on two pins, and then a 3rd pin-cell counts those steps, and gives a set point output action, that is probably possible 'in the pins'.
It seems to me that you may need no less than a PID loop between the quadrature encoder and the PWM. What can be done that is within the scope of simple logic?
IIRC, it was @briskmover who stated that he was performing motion control WITHOUT PID(!?!?!?). His post was very cryptic and then he disappeared from the discussion.
Fast RESET terminate of PWM cycle is also simple logic, between pins, I think is already supported ?
The Counter.MSB to Pin or !Pin, mentioned above, I think is already supported ?
If there is spare config, maybe pin-pin gating, for carrier modulated protocols like remote controls could be done, tho the speeds those operate at, is low.
We have no hardware handshaking right now.
Do you think it's needed?
The fastest USB interfaces are parallel, using a FIFO model. (ie with handshake)
The streamer is a natural to manage the data speeds, but it is hard to see how that can work as an overall system without hardware handshake.
As well as FIFO modes, for fewer pins and next-fastest FTDI also have Fast Serial Mode, which can go to 50MHz, but that also has a handshake.
See the other thread - the newest serial port design should allow testing that Fast Serial Mode to 40MHz with software handshake, and that will give some numbers on the turnaround delays involved in SW handshake.
A true resolver is dynamic in nature in that the resolution it can report is only as good as the equipment you are using to look at it. That said, at higher speeds, it is not as important to keep track of the fine resolution as much as it is the coarse resolution. Micro positioning only needs to apply during slow and/or a pinpoint stop location, in which case since you are traveling slower you can dynamically "dial in" to the finer resolution based on the equipment looking at the signal. Awhile back I did some testing with a resolver used on an industrial CNC to help a friend of mine whom makes repairs and designs such machines.
In the Resolver Test #1 video, a square wave from the Propeller drives a "primary" coil or "excite" coil on the resolver at a resonant frequency determined by a capacitor in parallel with the resolver "primary" coil.
Two secondary coils on the resolver arranged 90 Deg out of phase within the resolver provide the sine/cosine output. Both coils are also tuned to the same resonant frequency as the primary coil by way of a parallel capacitor placed across each coil. One of the secondary coils along with the excite signal from the propeller are shown on the Resolver Test #1 video.
In the Resolver Test #2 video, both secondary coils are shown as the resolver shaft is rotated by hand.
In the Resolver Test #3 video, an ADC needs to read both sine and cosine signals simultaneously in order to get accurate results. I modified the ADC object to read multiple IC's simultaneously using the same clock and individual data lines. I used two MCP3204 because eventually I needed X,Y, and Z. Since the Propeller is also controlling the excite pulse, I know exactly when to read the ADC at the peak of the sine wave. The coordic routine is applied in software to the ADC results to determine the proper Deg position to display. Output is exceptionally stable.
I'll point out again, that when the shaft is rotating rapidly using a resolver, you only need to look at the coarse position readings, it is only important to look at the fine position readings when moving slow and coming to a pinpoint stop location. Your software should control the trapezoidal ramp up and ramp down speed control and position counting.
Resolver Test #1 video = www.youtube.com/watch?v=X5svWfa6u04
Resolver Test #2 video = www.youtube.com/watch?v=-Rga4V77kLc
Resolver Test #3 video = www.youtube.com/watch?v=gh1rsBDZajo
No! What we need is a finished product! Don't make me have to get Ken involved! 'Cuz I will!
Thanks for the example, jmg.
Interesting, Beau. That third video makes a complete picture.
I agree.
+1: we need silicon. The details come out later. Every project that makes use of the unique features of the propeller will NEVER fail due to the fact, that a feature is not available that can be realized by other controllers, because for little money such a processor can be a companion and overcome those hurdles.
Agreed, I want to get this done so that we can move onto software.
I did get the 3-of-3 filtering added with selectable 1/8/64/512-clock sub-sampling, as someone provided a link to a while back.
Not quite - The specific question was around Handshake, which is a little different
Handshake is what is needed to make a feature already in P2, work properly in the field.
It is a real-world interaction requirement, that cannot be solved by 'adding another chip',
Instead, it is a (simple) feature required to talk to another chip.
The NCO Clocked nature of P2 links means there is already a Clock Enable, most handshakes simply adds an external pin optionally into that Clock Enable.
I haven't seen anyone even propose a solution for the kinematics issue. We have implementations to make lines and circles using Bresenham's algorithms, but this doesn't get you a correct feedrate in an arc, or on an angle. It requires hard coding the factor for screw lead and gear ratios or belt pitch to even get accurate movement at any speed.
A correct implementation will calculate the points along an arc, or angle, or even a straight line at the correct rate, and then the kinematics engines for each axis go to work to get the motor position targets, It would be VERY sweet to be able to just throw an equation that models the axis' motion, and a position target at an instance of the the kinematics engine, and get back a specific motor's target.
What if your motion axes aren't X,Y,Z? Just calculating real time X,Y,Z position and orientation targets for all the axes in something like a 6 axis robot is massive. The throughput of the CORDIC solver is what will determine the accuracy in terms of number of points per unit travel at a given rate. I have high hopes though, because several cogs can load the CORDIC at virtually the same time.
After all this work is done, we worry about keeping the motors on target. Of course, this must be very fast, or we increase 'following' error by too much. It's really a massive undertaking to get it right!
G code interpreter running yet? No, but really anticipating what may be done when I have a P2 on a board!....
The Pythagorean Theorem can be used in 3D just as easily as most of us are taught to use it in 2D to calculate the distance between any two points in a 3D space.
3D Pythagorean Theorem:
(x1-x2)^2 + (y1-y2)^2 + (z1-z2)^2 = distance^2
3D Pythagorean Theorem Reference:
http://betterexplained.com/articles/measure-any-distance-with-the-pythagorean-theorem/
Other measurement calculations are trivial, such as RATE, unit conversion, etc.
This gives rate in inches per min:
RATE = RPM/TPI = R/M / T/I = R/M * I/T
These are only BYTE wide conversions, but could easily be expanded to 16,24, or 32 bit operations
In PIC assembly language to convert inches to mm with a multiply function: (1 = 1mm ; 10 = 1 inch)
movf inch,w
addwf inch,w
addwf inch,w
mullw d'218'
movff PRODH,mm
In PIC assembly language to convert mm to inches with a multiply function: (1 = 1mm ; 10 = 1 inch)
movf mm,w
mullw d'101'
movff PRODH,mm
A similar method can be used to determine RPM based on the desired RATE and TPI (Threads Per Inch)
Suppose we need to normalize the RATE and the design engineers really wanted to jack with us an we have a different lead screw pitch on all 3-Axis:
X = 25.4 TPI
Y = 10 TPI
Z = 12.7 TPI
...to further complicate things, suppose we want to specify the RATE in (mm/m) rather than (inch/m) ... actually it's a bit easier in mm/m ... if you want inch/mm ... apply the "inch to mm" routine above prior to applying the RPM calculation below.
RPM = (RATE * TPI ) / 25.4
In PIC assembly language for the 'X Axis':
movf RATE,w
mullw d'255'
movf PRODH,w
addlw d'1'
movwf RPM_X
In PIC assembly language for the 'Y Axis':
movf RATE,w
mullw d'100'
movf PRODH,w
addlw d'1'
movwf RPM_Y
In PIC assembly language for the 'Z Axis':
movf RATE,w
mullw d'127'
movf PRODH,w
addlw d'1'
movwf RPM_Z
...The result is that now you have three different RPM's ( RPM_X, RPM_Y, RPM_Z ) you need to drive your Stepper, or Servo motor at that will produce a consistent "Feed Rate" on all Three Axis
Another derivative of "INTEGER division by way of Multiplying" as used in the above examples, you can calculate the necessary Period requirement based on the RPM values above and the number of steps it takes to complete ONE revolution on your Stepper, or Servo motor.
Again, most of the math is trivial, but with a little mental elbow grease and a big dry erase board it's not that much to tackle.
If Generating QUAD, (aka stepper) you would use 2 x NCO with Phase preset, to do any-Fo-Quad, and that can be feeding an adjacent Quad-Counter, preset to some set-point.
If Reading-Quad, you can have two counters in two pin cells, one Absolute version, and another that is your set-point/way-point difference, if you wanted that.
I think Prop can low power wait, on that way-point counter MSB.
That may also be possible now ?
It would need the Pin-Cell Counter MSB to MUX to the pin, as well as Internally.
The Pin can Flip polarity.
Absolutely agree that G code must be implemented in software.
Your calculations and examples are spot on, but fall a bit short of what I understand is needed.
For example, Feed Override. Not a problem your way, if it doesn't change during the cut. Then, what about a manual pulse generator? Even antiques like the Allen Bradley 7370 implement these. As well as not-so-antique Mach 3 and LinuxCNC.
You could change the 'master clock' rate that hopefully all the axes are geared to, but staying on a path, especially an arc, with the ratios locked like that would get hairy fast.
To meet these conditions, You're back to calculating each point on the path, varying the rate of motion of the target position according to the MPG or override, with acceleration, and then letting the motion routines go to work trying to hit the moving target position. (This info also very handy for real-time path display..)
Again, I agree that Prop2 will be up to it!
Again, I find myself reflecting on the amazing job the Engineers of those old CNCs did with what they had. DC servomotors with massive armatures (by today's standards), controlled by SCR amplifiers with maximum 180 hz bandwidth... Amazing that it worked at all, More so with amazing precision, and that some of them are still doing competitive work...