Advanced Search

@Lcvette:

I just checked in to the forum to report that I'd found a parameter variation between my probe_cal_round_pocket version and the one on GH...

Too funny.  I'll get the latest version in a sec.

Regarding the erratic behavior, I added some dbounce and it was worse at delay=10.  Turning it down to delay=2 seems to have sorted things out for now.  Multiple probing attempts were successful - no fails - but the jury is still out.

Relayted question...  I found an error in the terminal at the end of the calibration routine:

Is this something different, or related to the incorrect parameters in the subroutine?  I wasn't able to find any "calibration_offset" widget in either my installation or on PB/QTPYVCP github pages.

yeah that's definitely an issue. its -0.11V by default and in one direction, and 0.03V in the other direction.

If you have a DVM/Multimeter, try measuring the voltage between dir+ and dir- on the Mesa connectors or on the drive connectors, wherever is easier for you, measure while jogging the measured axis, should be +4-5V in one direction and -4-5V in the other direction.

Yes I have the original config, just tried it and the same behavior persists and nothing moves. However, the position values change when homing / jogging.

I found there was an error in the ring calibration subroutine, it was corrected in the most recent update, so you will want to run apt update for that fix.

Do you still have the original config?
Try if that runs OK, or make a quick new config for testing using Axis GUI.

Sorry Benb, my bad, i just noticed it is looking for the homing.c file in the dev folder.
Thank you for bringing that to my attention, very much appreciated.

Hi Guys,

Thanks for your responce's.

@Automata, when time is ready, will check you back for the servo's. I think that's nice to have around here.


We have some results today.
When the buffer is loaded and path is optimized, it writes a gcode file named "validation.ngc" into the ~/cmake dir.
Then you can load this file into lcnc and check results.

Some times the path optimalisation fails. So have to look what's going on.

I have to dive deeper into the original lcnc circle math. As this gives sometimes error's at lcnc runtime.
The message is like "arc radius differs ..." Most of time around 1.4%.
It's now late. Will check some things tommorow.

Attached some test pictures. I used also chamfer fillets for test. And bsplines.

Hello, first time posting.

I have a gantry style mill setup using servos on three axes, controlled with a Mesa 7I96S, and using the probe basic interface. It has been working fine for nearly a year now, despite a realtime delay warning at startup, which I haven't gotten around to fixing. But that is not my main issue (maybe it is). Today, after the machine homed itself, I was unable to jog any of the axes, and then was not able to home the machine, even after multiple restarts.

I checked all the servo power/enable lights, they were all good, the power supplies were all providing the proper voltages, and the Mesa board did not have any red error lights. When running LinuxCNC through terminal and homing, the only error shown is that single realtime delay error on startup. When pressing home after enabling the machine, the feedrate changes from zero to the homing feedrate, but the tool position values do not change and nothing physically moves. After one of the restarts the position values did change, but the machine did not move, which confused me even more. Manually jogging doesn't do anything now since it refuses unless the machine is homed. The fixed-speed spindle relay can still be toggled. The servos hold their positions, but that is of course because of their integrated controllers. 

I am at a loss for what the issue could possibly be, and why it happened out of nowhere, and would love some pointers/to know where to look.
Thank you for your help!

Hey Tom, I am complete dummy when it comes to Linux OS. ?However, since I started using RIP I know where all pieces of the programs I loaded reside. For non linux savey it makes it easy to troubleshoot. As marq_torque indicated he does not know the location of hos files. marq_torque Once you install rip all your linux files will reside in Linuxcnc directory. If you follow the procedure all your linuxcnc files will reside in /dev/linuxcnc.

Do I need to have the axis offsets loaded?  In the 429remap.ngc G10 is loading axis offsets.  Is it necessary for either genserkins or idenity kins?

A .tap file is not an image file, it is a SheetCam g-code file so you would not want it to call image-to-gcode. Try commenting it out in the FILTER section.

 

 

I'll add a debounce filter later tonight and see how it goes.  I was tempted to get the latest v9 WLR because it has the spin-to-wake function - nice for keeping it in the ATC.

Temptation is dwindling, however.

?