Advanced Search

So I tried physically swapping the Y2 dir- and dir+ , but it didn't help the end result any


If swapping DIR+ and DIR- (on the drive _or_ 7I76 end only) does not change the Y2 direction,
There is a hardware or wiring issue.

Hi Tommylight

Thank you for the info, much appreciated

You were correct on both counts. 
I didn't want to ask how you knew one of the Y motors is reversed,  without first trying to figure it out myself first.

As you can see from the attachment text doc below,  I tried a few things, but I was not able to figure it out.

What (which fields) caught your eye ?

My Y1 jogs in the correct direction, my Y2 jogs in the opposite direction. 
Many thanks

***********************************
The long version of what I tried ....

The config attached is my last known good which Homes all three axis (with a but ...)

(X zero, and Y zero, is front bottom left - when standing in front of the machine , looking at it). 


But ...


if I move the Y axis gantry as a whole , after homing completes, (jogging just 1mm at a time)

the Y1 gantry motor goes 1mm towards the rear of the machine (which is correct)

and

the Y2 gantry motor goes 1mm towards the front of the machine (which is incorrect)

So it just ends up racking the machine in slow motion


I tried very many settings, and eventually lost my way, and ended up relentlessly crashing the Y2 side of the machine


I don't know what settings to try to get the Y2 motor to Jog correctly, without affecting the Homing

***************************************************************

All motors are wired in exactly the same order, from the drivers to the motors

So I tried physically swapping the Y2 dir- and dir+ , but it didn't help the end result any

**************************************************************

I also made a config of just X and Y1 and Y2 (no Z) and NOT as a gantry (but as independent motors)
and was therefore able to bypass gantry Homing (as without homing, the gantry won't move)
each motor ran in the correct direction, when independently jogging a few mm at a time 
(testing that there wasn't a physical problem with either the wiring or with the motor drivers) 

**************************************************************

I also found that by making another test config using mesaCT, a with and without, a y2 reverse direction tick, it added two fields
STEP_INVERT= False
DIR_INVERT = True
I only tried the "DIR_INVERT = True" on the Y2 joint which didn't help either

**************************************************************

To recap

I have been able to make the homing of all three axis Home (although the signs still make no sense to me)

I have been able to test the x and y1 and y2 motors working in their correct jogging direction (when not in a gantry mode, and not homed)

I am unable to make the machine do BOTH things (Home AND then Jog the Y axis gantry with Y1 and Y2 in sync together, so gantry doesn't rack)

**************************************************************


My "process" for testing positive and negative homing values 

Start by setting the Y axis gantry of the machine to 25mm (width of a ruler) , so both Y1 and Y2 motors 
Have the same distance to travel, from their respective proximity sensors to the steel it senses against (so the Y axis gantry always starts from a known position)
Set all the signs of the values to positive on both y1 and y2 joints (in Geany)
Switch the power on to machine , and mesa cards
Wait for notification that ethernet is connected 
Launch LinuxCNC
Select the config
Estop off, machine on
Home all
Watch which direction the gantry begins to move on both Y1 (left side) and Y2 (right side)
If it goes in the wrong direction , change the sign  
Repeat for each of the 4 iterations of homing one axis

The attached file , Homes as the photos show. (But Y2 jogs in the opposite direction)

Just incase there is some random element to this somewhere , I re-ran this Homing configuration successfully, ten times in a row. 

**************************************************************





 

@grandixximo
The machine is congigured with a 1ms servo cycle, the speed with 15 m/min, the acceleration with 5 m/s² and the jerk with 50 m/s³ so nothing unusual for servo axes.
P64 P0.01 Q0.0 is also not unusual.
In my opinion, the limits for jerk, acceleration and speed should not be exceeded so that the behavior of the machine is predictable.
The unusual thing from my point of view is that MAX_LINEAR_JERK and MAX_JERK are different.
If there are restrictions on certain parameters, please let me know so that I can take them into account in my tests.

I really needed a slap upside the head!

Blame this on me, despite me writing this a few posts back:

tommylight wrote:

You still have the:
....

I was convinced the comp issue is separate from this one, and was wondering why are you testing the comp since it is not mentioned in the error report...
Should have raised a flag ... or a smoke signal, wold have probably been more useful.

Oh. Doh!!!!!

Thanks a lot. I was so focused on the comp, I missed the obvious.

Hmm.  I didn't check on a sim, just my real hardware.

My backplot jumps when I do the switchkins switch, but no amount of fiddling could get the hardware X-axis to move when I had velocity set to zero.

I understand.

I would have chosen that approach.
First, set up a system where the module runs, and then read the communication data.
I think it’s very consistent of you not to use Windows.
Respect.
As far as I know, there are also system managers that run on Linux.
Would that be an option?

Aciera wrote:

Are looking at the right file? The error is in 'turret.hal' (ie the hal file) NOT 'turret.comp' (the component)

Yes, this.

I went through all the recommended steps on the forum with the exception of clearing the disk of Windows and partitioning the whole disk as MBR and then reinstalling windows.

Are looking at the right file? The error is in 'turret.hal' (ie the hal file) NOT 'turret.comp' (the component)

tommylight wrote:

You still have the:
.turret.hal:1: Unknown command ''
error, there is something on the first line of that file causing the error.
Try running it through a dos/win to Linux script, might be some strange character there.

 

Yeah, I see that too.

I tried a few different ways to identify and remove strange characters, and even completely rewrote the code by hand into visual code studio. It compiles without error and runs without error in Halrun, but only fails as part of a full linuxcnc start.

RotarySMP wrote:

If I fall back on somehing like 2.8.4 buster ISO, do I loose your latest macros layout?

I think that it should work as long as you have GTK3

Might have better luck searching the Debian forums with this, although win11.....

Bump.
They post plenty of new videos, but i did not have time to watch them.