Accumulated travel distance for axes

More
09 Jan 2017 09:34 #85506 by perra_e
I have tried to figure out if it is possible to accumulate the distance the axes are moving.
I have a reccomended service interval (lubrication) of 2km for my mill and it would be very nice to get this information out of the mill instead of guessing!

Has any one done somthing like this?
If it is not possible, I'm interested in adding this feature to Linuxcnc.
I guess that I'm not the only one that would like this.

--Per

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

More
09 Jan 2017 14:12 - 09 Jan 2017 14:22 #85516 by Todd Zuercher
What kind of axis do you have?
This might be pretty easy for a software stepped system. (In other words I think I have an idea that may work.)
A hardware stepper or servo may require more thought, but should still be possible. (In other words, I don't have an idea how to do this, yet.)
Last edit: 09 Jan 2017 14:22 by Todd Zuercher.

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

More
09 Jan 2017 14:58 #85517 by perra_e
Unfortunately I have analog servos with Mesa 7i77 interface. So we are in the "don't have an idea yet" territory :-)
I'm absolutely willing to try to develop this if I get a hint where to start!.

--Per

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

More
09 Jan 2017 15:44 - 09 Jan 2017 15:47 #85519 by Todd Zuercher
Ok I think I have another idea that should work for all situations, but it may not be the best or cleanest way to do it. and I don't quite have all the pieces of the puzzle. (hopefully if someone has a better idea they'll chime in.)

There are 3 key steps to making this work, 1st getting the absolute distance traveled, 2nd remembering the distanced traveled between Linuxcnc sessions and restarts, and 3rd triggering your warning, or lube cycle at the required maintenance interval.
Here is a rough sketch of the hal work to implement the 1st step for one axis.
1st step, using the abs component connect the axis.N.joint-vel-cmd pin to the input of an integ component. The output of the integ component would be the total distance traveled since starting the machine (or since the last reset of it)

I'm not sure about how to implement the 2nd step.

The 3rd step seems simple enough, so I won't go into it now
Last edit: 09 Jan 2017 15:47 by Todd Zuercher.

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

More
09 Jan 2017 17:08 - 09 Jan 2017 17:10 #85528 by perra_e
Fantastik, it works ! This was the hard part for me!

If there is no ready hal component that can save the result it should not be too hard to write one that saves the distance to a file. It can be triggerd when axis.n.amp-enable-out goes low for instance. and at the same time reset the integ component.
Spontaniusly I Think of the following pinns:
in1 - actual Count ( from integ). Or even better, do the abs and integ inside the component and just connect axis.n.joint-vel-cmd
in2 - Trigger for write to file
out1 - reset integ (if not internal)
out2 - Total Count (saved + actual Count)
out3 - Alarm service distance.

param in 1 - Distance for service alarm

This was exciting! I will start with this tonight.

--Per
Last edit: 09 Jan 2017 17:10 by perra_e.

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

More
09 Jan 2017 17:37 #85532 by Todd Zuercher
One neat thing about the integ component is you could input the stored distance value to the integ.N.min pin and that would set the integ.N.out startup value. But you might have to work out how to reset it back to 0 when you need to restart your count.

Maybe this would be helpful for the hal pin persistence?
wiki.linuxcnc.org/cgi-bin/wiki.pl?Contri...ents#Parameter_Saver

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

More
09 Jan 2017 17:51 #85533 by perra_e
It looks like it is possible to solv the persistance with this component. I will give it a try.
In worst case one can reset the counters to zero by editing the file!
--Per

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

More
09 Jan 2017 20:00 #85545 by perra_e
And here we have a solution that works in gmoccapy sim:
loadrt abs names=abs_spindle_feedback,abs_motion
loadrt integ names=motion_tot
loadrt not count=1
loadrt and2 count=1
loadusr -W paramsaver f=1 s=0 b=0 filename=persist onstart=0 onexit=0 

addf abs_spindle_feedback servo-thread
addf abs_motion servo-thread
addf motion_tot servo-thread
addf not.0      servo-thread
addf and2.0     servo-thread

# estop loopback
net estop-loop iocontrol.0.user-enable-out => iocontrol.0.emc-enable-in paramsaver.readtrigger and2.0.in0

net motion_in abs_motion.in <= axis.0.joint-vel-cmd
net motion_1a abs_motion.out => motion_tot.in comp_moved.in1
net motion_1b paramsaver.invalueF-000 <= motion_tot.out
net motion_2  motion_tot.min <= paramsaver.outvalueF-000
net motion_3  axis.0.amp-enable-out =>  not.0.in
net motion_4  not.0.out => and2.0.in1
net motion_5  and2.0.out => paramsaver.writetrigger

thanks a lot for the help!!!
--Per

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

More
10 Jan 2017 19:16 #85581 by perra_e
I thought this was solved. It works perfect in simulation on a virtual PC, but on my mill the paramsaver does not save anything when I trigger writetrigger! Any ideas on this one?
I'm running RIP-Environment.
Attachments:

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

More
10 Jan 2017 20:06 #85585 by Todd Zuercher
Does your persist file exist? In your vm test where was the persist file saved? Maybe the rip config can not access that location?
You might have better luck asking this question on the mailing list.

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

Time to create page: 0.161 seconds
Powered by Kunena Forum