Dynamic HAL spindle encoder scale

More
06 Nov 2017 12:06 #101415 by Nitram
Hi.

I have a spindle, with two belt ratios. The encoder is on the motor side and this encoder drives the RPM loop, thus following a belt change the rpm at the spindle is incorrect as the encoder scale is incorrect for the other belt ratio.
There are only two belt positions/ratios specifically 1:2 and 2:1. I currently have two macros written and remapped to M codes for the lo_to_hi and hi_to_lo belt change routines. The machine is primarily used in hi range across the board, but sometimes if higher torque is necessary it is sometimes operated on a rare basis in low range. In all cases belt selection is controlled manually, either by the operator at the machine (by me), or via the post processor with M codes (by me). There is no logic necessary to dictate that below xxx RPM the low belt MUST be used or that above xxx rpm the high belt MUST be used.

So, as there are only two positions and they are always of a known ratio, I feel that the most transparent logic (if "do-able") would be to have the encoder scale change incorporated at the end of the belt change macro/M code, so that the encoder scale follows the ratio currently in use and in that way holds the correct RPM at the spindle.
For the high belt (1:2 ratio) the encoder is currently scaled to 2000 (i.e. 1000 count encoder at the motor and inclusive of the belt ratio).
Thus with low belt selected (2:1 ratio) the encoder scale would need to be 500 at the motor.

So a few questions:
1. Is there any HAL function which I can use to check the state of a signal to define which belt is currently in use (like an M66) and then following a belt change and based upon that signal, output the required encoder scale accordingly to
setp hm2_5i24.0.encoder.04.scale [SPINDLE_9]ENCODER_SCALE

Or
2. Can a HAL variable be brought into a macro (.ngc file)? i.e. have the [SPINDLE_9]ENCODER_SCALE be reassigned by the macro whenever the macro is called, i.e a belt change is made?

Or:
3. Can a user variable (eg. say #4998) be brought into either the ini or hal file? (I suspect not on this one, as if I recall correctly, the ini and hal files are only read upon initialization of linuxcnc and thus would not be read again to recognize a change of variable subsequently).

So I'm hoping there is a mechanism to have two encoder scales available in the hal file (or elsewhere) which can flip flop as the operator changes belts.

Thanks for the input,
Regards,
Marty.

Please Log in or Create an account to join the conversation.

More
06 Nov 2017 16:35 #101437 by PCW
Unfortunately you cannot change the encoder scale dynamically, because it is a parameter, not a pin.

This can be done however by using a combination of the mux2 and scale components

Please Log in or Create an account to join the conversation.

More
06 Nov 2017 20:19 #101463 by andypugh

Please Log in or Create an account to join the conversation.

More
07 Nov 2017 09:36 - 07 Nov 2017 09:38 #101486 by Nitram
Hi Peter, hi Andy.

I fought with this all day, with limited success. As you said Peter, the encoder scale, being a parameter would not allow any changes, even via a mux2 function, the float value was simply not accepted as valid...

Andy, I tried writing into HAL the gearchange function. I set the ini file to an encoder scale of 8000 which is representative of what is needed for the low belt to run on the correct RPM. As the gearchange function defines "the scale of gear 1 is assumed to be 1" and is effectively the basis for the gearchange function (gear 2 always being the higher geared ratio), hence the encoder scale was set to this base value to allow the gearchange function to make the necessary changes. (Noting that the encoder is on the motor, not the spindle i.e. upstream of the spindle rpm via the belts).

So, try as I might, I think my old nemesis, syntax, is working against me again...
Have included the spindle part of the HAL file (attached) inclusive of the gearchange function attempt.
If you get a spare minute could you give it a peruse and see whether I am on the right track, or indeed, whether the gearchange function will work in this context.

If I can get the spindle in synch inclusive of belt ratio, the goal is to be able to rigid tap in either hi or low range, enabling the user to decide (based on tap size) what level of torque (and thus what belt ratio) is most appropriate for the given thread size and material being tapped.

Thanks and kind regards,
Marty.

File Attachment:

File Name: SPINDLES.doc
File Size:30 KB
Attachments:
Last edit: 07 Nov 2017 09:38 by Nitram.

Please Log in or Create an account to join the conversation.

More
07 Nov 2017 09:54 #101487 by andypugh

If I can get the spindle in synch inclusive of belt ratio, the goal is to be able to rigid tap in either hi or low range, enabling the user to decide (based on tap size) what level of torque (and thus what belt ratio) is most appropriate for the given thread size and material being tapped.


I don't think this can be made to work properly, unless you are 100% certain that no-one will ever attempt to peck-tap on the machine.

The index needs to be at exactly the same point on each spindle revolution so that the thread starts at the same point. This does only really matter if you are trying to re-enter an existing thread.

The best solution to this is to add an separate index sensor actually on the spindle. It can detect a keyway or a drilled hole, bolt head or anything similar.

Please Log in or Create an account to join the conversation.

More
07 Nov 2017 12:25 - 07 Nov 2017 12:28 #101488 by Nitram
Actually the machine is rigged as you say, a hall sensor on the spindle is being used both for orient (tool change) and also for the index pulse for rigid tap. In other words the encoder on the motor provides the A /A and B /B for spindle to Z synchronization whereas the hall magnet on the spindle provides the index pulse.
On a side note I had the index pulse (hall sensor) up on halscope. Below about 2000 rpm I would be easily able to confirm commanded rpm was being achieved at the spindle with the time between pulses in milli seconds on the scope. I.e .060 second intervals = 1000 rpm at the spindle. HOWEVER as the rpm was increased over 2000 rpm the time interval between pulses never got less that .030 seconds (2000 rpm) even though the machine was clearly singing and the vfd rpm readout read correctly (encoder driven).
Even at 10000 rpm the time between pulses was still consistently at .030 seconds. Halscope is up at 1khz sample rate so should be able to easily get better resolution than this.
Is there a limitation with the number of pulses a hall magnet can output? Does halscope have limitations on sample rate in this area? Where is the bottle neck?

This is quite interesting. But it doesn't really affect the operation of my spindle.
Are there any suggestions to set up the belt change on my machine. Have tried a few things now with limited success.
Last edit: 07 Nov 2017 12:28 by Nitram.

Please Log in or Create an account to join the conversation.

Time to create page: 0.216 seconds
Powered by Kunena Forum