Hickory max encoder input speed

[spikee]

Hi, I was just thinking about adding scales to the hickory... cause why not

One thing I noticed in the Manual is that the Hickory supports up to 1.2MHz input speed on the encoder input.
Which is not bad, but considering if you rapid at 50-60m/min , that limits your resolution of the scales.

What I noticed in the Oak datasheet is that it allows you to go up to 6MHz, after changing a parameter bit. Considering the Hickory is presumably an evaluation upon the Oak I would almost imagine that the same trick can be done for the hickory. is that true?

[eng199]

Typically encoders will not output over 1MHz. Often they are 300kHz to 500kHz maximum.
Scales or encoders that are high resolution and high speed will typically use a serial protocol rather than A/B quadrature.

It is unlikely that the 1.2MHz limit is an issue.

If you really intend to use scales that support unusually high frequency, we can double check the functionality of P323 high speed filters with HICKORY. The feature does appear to be implemented, but it needs a re-test because it was not intended to be used.

[spikee]

Hi, unless i missed something the hickory does not support serial protocol encoders?

I will have a think about what kind of resolution i want for the encoders and if that fits the 1.2mhz limit.

[eng199]

The 3 DE9 connectors on HICKORY do not support serial protocols. At some point, an encoder expansion board will be released. It has BiSS support.

[spikee]

Thank you for the feedback. I will keep it in mind

[juspk]

Typically encoders will not output over 1MHz. Often they are 300kHz to 500kHz maximum.
Scales or encoders that are high resolution and high speed will typically use a serial protocol rather than A/B quadrature.

It is unlikely that the 1.2MHz limit is an issue.

If you really intend to use scales that support unusually high frequency, we can double check the functionality of P323 high speed filters with HICKORY. The feature does appear to be implemented, but it needs a re-test because it was not intended to be used.

I'm in the process of a Hickory build and I have a programmable encoder for my spindle. My spindle will max out at 8000 rpm. With the Hickory limited to 1200 KHz does that means I'm limited to 9000 PPR? While I understand that is definitely enough resolution, it would be nice to use more since I have it available. My question is, did P323 ever get implemented on the Hickory like it is on the Oak controller?

[eng199]

Even if your encoder supports that rate, I can think of no reason to do it.
The index pulse is a critical signal for the spindle encoder and you will be making it incredibly short. The better option is to keep the line frequency below 1.2MHz and make sure P323 is set to 127. This improves noise immunity, while the alternative is unlikely to improve anything. Running multi MHz signals through a noisy environment should be avoided, which is why very few encoder manufacturers provide those rates.

The purpose of the high frequency input was to allow 3rd party drives to run high rates into MPU11 systems for velocity mode. Those systems typically had a cable 5 or less feet in length from the drive's encoder repeat. The feature was not intended for scales or spindles with long cables leaving the cabinet.

[cncsnw]

make sure P323 is set to 127

Am I missing something here?

The operator's manual says that P323 is a bitmap by axis number.

Therefore, P323=127 would be selecting the low-speed filter for axes #1 through #7.

However, prevailing practice on Hickory systems seems to be to assign the spindle encoder as axis #8.

Wouldn't that require P323 = 255 (or at least, P323 = 128) to apply the low-speed filter to the spindle encoder as axis #8?

[eng199]

Thanks for pointing that out. I'll get the manual fixed.

P323 bits 5..0 correspond to MPU11 encoder plugs 6..1. Bit 6 is the MPG. This is the hardware level numbering, which differs from P308-315, where the MPG is 15.

I did notice that P323 has no effect on MPU13/HICKORY. The filters are implemented, but there is no pathway for the parameter value to get to the filter module.