Retrofitting Mikron WF41C: Distance coded homing success

Hello @gaston48,

today we recorded a bunch of operations on the Mikron. Regarding lubrication I found the following:

All the lubrication cycles issued by the machine are approximately 15 sec.

At startup there are two 15 sec cycles interrupted by a 15 sec break (see first picture and data attached).



During a repeated sub-program run where the machine did a 100mm circle followed by a 100mm up and down move with Z I found that the machine is issuing as well 15 sec lubrication cycles from time to time.



Between the two lubrication cycles the described program run pretty much exactly 40 times i.e. each axis traveled 8000mm and did 80 direction changes. I assume that the distance triggered the lubrication.

I hope this is useful.

Best regards,

Marc

PS:. The attached *.txt files are actual *.csv files, but the forum did not allow me to upload them as such....

mwinterm wrote: But then I'm missing how to set the output of the encoder to the current position that it can feed the right input into position-fb.

The HAL component would need to sit between motion and encoder. It would have an index-enable-in and an index-enable out, and position-in and position-out. Also rawcounts-in. On joint.N.index-enable going true it would set the encoder index-enable, wait for it to go false, store the counts, set the enable again, then calculate the position. It would then add an offset on to the position-in from the encoder and output it to the joint--fb as an absolute position.

The only option that I see is that the HAL-component could set the HOME_OFFSET.

HOME_OFFSET is available on a pin (ini.X.home-position) but that pin is serviced as a userspace process so wouldn't necessarily be read at the right moment.

mwinterm wrote: Hello @gaston48,

today we recorded a bunch of operations on the Mikron. Regarding lubrication I found the following:

All the lubrication cycles issued by the machine are approximately 15 sec.

At startup there are two 15 sec cycles interrupted by a 15 sec break (see first picture and data attached).

During a repeated sub-program run where the machine did a 100mm circle followed by a 100mm up and down move with Z I found that the machine is issuing as well 15 sec lubrication cycles from time to time.

Between the two lubrication cycles the described program run pretty much exactly 40 times i.e. each axis traveled 8000mm and did 80 direction changes. I assume that the distance triggered the lubrication.

I hope this is useful.

Best regards,

Marc

PS:. The attached *.txt files are actual *.csv files, but the forum did not allow me to upload them as such....

Thank you very much Marc,

I will adopt a 15 second operating delay
I consulted the TNC 355 documentation, you have the same parameters
than my TNC 407, only on the distance traveled

you must find the parameter = "122" (8000000/65536)

good continuation !

@andypugh: That is for sure also very easy and doable. But it means that the position is routed and modified by this HAL component. As the positional feedback especially with the high resolution glasscales is high-frequency and very critical for accurate motion control is there no concern adding an additional component into that data stream (i.e. adding delay)?

Regard,
Marc

mwinterm wrote: is there no concern adding an additional component into that data stream (i.e. adding delay)?

Not if the component is the first thing in the HAL thread after the IO read. (so, after the parport read or the mesa card read, typically)

LinuxCNC runs a read - process - write cycle every 1mS.
As long as the motion control system gets a "fresh" position feedback then it's all good.

Hello,

here now another update on the retrofit project of our WF41C.

We have now connected the LinuxCNC control with the machine and can control all the axis. However there was a little journey to that point. We fought a while with getting the signals from the glasscales. First we thought that some of our little interpolation boards were buggy as we could not get the Y-axis to run. But then it turned out that this was not the case as all the boards were running fine on some encoder inputs of the 7i77 and were unstable or not working at all on some others. Next suspicion was that the 7i77 has a problem... also this proved to be wrong. At the end it turned out that the cable between the 7i92 and the 7i77 was the problem. When exchanged with another one everything worked fine. However it took us some time to get there as we tested the faulty cable a number of times pin by pin and even checked for connections between neighboring pins and could not find anything... still strange to us. But non the less the cable definitely caused this strange behavior with the encoder inputs of the 7i77. All the rest of the card was working fine all the time.

After we sorted that out we established the right signs for the scale factors of the analog inputs (positive voltage = movement in positive direction) as well as of the glassscales (movement in positive direction = increase in position feedback). During that process there were some surprises with the Z-axis and its brake. We thought before we activate the servo drive we release the brake not having the servo working against the brake. When doing so we were expecting that the table might slowly move down. But we were very surprised how quickly the table was sliding downwards and before we could activate the servo amplifier it was already tripping the emergency limit switch. As at that point we didn't know the right sign for the analog output yet we had to reconnect the Heidenhain control, researching the procedure to move an axis out of the emergency limit switch (there is a switch in the electric cabinet that bridges the circuit of the emergency limit switch) and move the machine out of that position. After that we reconnected the LinuxCNC control.

Then we basically had the machine moving using the PID values from Gaston48. However even though moving correctly the machine didn't sound happy. So we decided to tune the PID values ourselves from scratch following the servo tuning procedure of gnipsel ( gnipsel.com/linuxcnc/tuning/servo.html ). This was very quick and efficient. After about half an hour we had the x-axis tuned already very nicely with following errors below 0.002mm while moving and maybe 0.003mm max during acceleration and deceleration when doing short jog-moves at 1500mm/min. The values found for our machine (optimized on the x-axis but also working pretty well on y and z) are so far: We were surprised that the optimal values for our Mikron WF41C deviated that much from the values Gaston48 had found for his slightly newer version of the same model.
We also found a little bit of drift on some axis that we could easily compensate with the BIAS value (we didn't want to adjust the potentiometers on the servo amplifiers as like that we keep the option to switch back and forth between the Heidenhain and the LinuxCNC control).

Finally however during that tuning process at one startup we had a mishap as the machine was crashing with the y-axis at full speed into the mechanical limitation. Halshow showed 0V on they y-output but we could measure nevertheless 10V on the 7i77 y-output with the multimeter. We have no understanding why this happened. It also didn't happen since anymore. But the aftermath of this incident is that we damaged the y-Axis which has now around 0.02mm backlash. First inspection points towards the fixed bearing block of the ball screw which would not be too bad to repair (much better than the ball screw itself anyway).

Best regards,

Marc

mwinterm wrote: Finally however during that tuning process at one startup we had a mishap as the machine was crashing with the y-axis at full speed into the mechanical limitation. Halshow showed 0V on they y-output but we could measure nevertheless 10V on the 7i77 y-output with the multimeter.

This sounds like it should have tripped a following error and disabled the drives? I have never heard of a 7i77 doing that. I wonder if perhaps the 10V was coming from somewhere else in the wiring?

We had the same suspicion.... but no, we disconnected everything and still had the 10V.
We were continuously tuning some stuff and might have introduced some typos in some places. Unfortunately I don't have the very configuration that caused the problem anymore. But I'm still wondering what kind of error I could introduce in the *.hal or *.ini files that could cause such a behavior (halshow showing 0V and having 10V on the output).

Not helping, but, i have at least 5 or 6 of the Mesa 7i77 installed on industrial machines plus two i use for testing, never had any hiccup, ever.

Hello,

I just want to clarify that I'm not blaming anyone or anything. In a project like this there is always a chance that something like that can happen. The reason I'm sharing this and what is bothering me the most is that I don't have a clue why it happened. Making mistakes is not so bad as long one can learn from them...

In that sense I would like to share in more details to the interested what happened exactly.

1. While tuning some parameters in the *.ini file (like max speed, acceleration etc) we accidently moved the y-axis into the limit-switch.
2. It has to be noted that the Mikron is normally operating with software limit switches. The hardware limit-switches are part of the e-stop chain. Once an e-stop limit switch is triggered there is a hardware switch in the electric cabinet of the machine that allows all limit switches to be bridged to allow to move the machine out of the limit-switch (obviously carefully as there is no additional layer of safety when these switches are bridged).
3. To move the machine out of the e-stop I decided to do this by directly applying a voltage to the out-put of the 7i77 as the PID was not nicely tuned at that point yet. To do so I disconnected the PID from the output of the 7i77. I still had a signal called y-output connected to the output but no seed into that signal
4. Then we restarted LinuxCNC without any problem i.e. reset e-stop, power-on and activated the feed-drive signal of machine (the machine has to layers to switch on the servo amplifier, first the feed-drive needs to be activated which activates a contactor to provide power to all the amplifiers, second each amplifier has to be 'approved' for motion individually. At that point none of the amplifiers were approved for motion yet.
5. Then I started halshow and picked the y-output signal to visualize which indicated 0.
6. Next I issued
   Code:

   halcmd sets y-output 0.5
   0.5V causes the machine to move rather slowly. Halshow indicated y-output to be 0.5.
7. My colleague now bridged the e-stop limit switches and I issued
   Code:

   halcmd sets _A23_axis_2_approve true
   which approves the y-axis for movement.
8. Crash, boom, bang..... machine crashed with full speed into the mechanical limit, servo spins on the tooth-belt, colleage releases the switch that bridged the limit switches. Stillness. :huh: :huh: :huh:
9. Halshow still shows y-output 0.5
10. Multimeter measurement on 7i77 shows 10V
11. We disconnect the servo-drives from the 7i77 but the 10V persist
12. I issue several
    Code:

    halcmd sets y-output ....
    with no effect on the actual physical output which stays at 10V
13. I issue
    Code:

    halcmd sets x-output 0.5
    and the x-axis output on the 7i77 shows the 0.5V correctly.
14. I restart LinuxCNC. Halshow again shows y-output to be 0V but we still measure 10V (Mistake 1: we did not measure voltage while LinuxCNC was not running)
15. Warning, no we really messed it up: I reverted my git-repo to the last good configuration I committed without saving the configuration that caused the problem... To make it even worse we rebooted the control (disconnect/reconnect power).
16. Everything runs normal again. Problem never happened again since... We have not clue what the problem was... :S :S :S

Regards,

Marc