Advanced Search

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.

Interesting. Just checked on a sim on 2.10pre and setting ini velocities to 0 does not quite work for me. The tool moves to the start of the spiral and then moves back. A bit strange really:

 

Same on 2.9.8

thats true, i did that because we now listed everything here in the docs. I will remove the machine setup file ini since it can be copied directly from the docs page instead and will be kept more current. good looking out susan-parker!

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.

Hans contacted over the github bug tracker, to have me run the Gmoccapy lathe sim, and sure enough, there is no scaling error behaviour there.

So I also tried the Gmoccapy Lathe_Macros sim, and that has the scaling behavior error.

When I created my current config, copied my old 2.8.2 config files, and cut paste the lathe macro files from this sim. Any ideas where I need to look for corrective action appreciated.
Cheers,
Mark

 

I tried running just the turret.comp under halrun, and have the same result as Andy. It works.
 

But when I call it from my custompostgui.hal, it errors out. See attached error logs.
Cheers,
Mark
 

That worked like magic.

I removed all the jog-disconnect stuff from the M-codes and substituted
in the switched-mode M-code file, and the opposite in the normal-mode M-code.

Switchkins still works: parting slide is still connected to the X-axis controls, but the V-axis/Joint_0 simply doesn't move.

• Axis GUI jog controls do nothing (!)
• G-code V-axis moves do nothing
• MDI does nothing
• V-axis jogging does nothing (via MPG or continuous buttons)
• No following errors or other issues noted

Best part is if I command a G0 Vnnn via MDI and then switch the axes back to normal, nothing 'jumps' like there's a blocked command waiting to be unblocked or re-enabled.

I'm probably missing some odd situation where this could bite me, but the fact is I'm only planning to use this switched mode briefly while the parting tool is in action (during a program) and then immediately restore the kinematics.

See any 'gotchas' with this?

Hello,

i bought this Sieg Typ Mill SX 3.5 from Paulimot in Germany. I now need to buy Steppers and Drivers. 
This is the Mill:  sieg-sx3.5z i bought the mill with glas scales and i like to implement them in the driver if possible?

I am thinking of getting the following Driver and Steppers, if this makes sense:   400-w-ethercat-ac-servomotor-kit 
it would be nice if the experts can give me a feedback because iam quit new to this topic. 
thank you 

I think I just found what may be a stupidly-easy solution:  set MAX_VELOCITY to zero.

I set AXIS_X & JOINT_0 max velocity to 0 in a test INI file and LCNC started up with no complaints.

Z-axis homed first, then X just sat there doing nothing - as expected.

Next test will be to edit the switchkins M-code and try it after everything is homed.

This may be of interest:
github.com/LinuxCNC/linuxcnc/compare/mas..._axes_in_interpreter

Adds a magic comment (disable,xyzabcuvw) to the interpreter. This allows the operator to disable any axis words (ie any of 'xyzabcuvw') in the interpreter. If the interpreter finds a disabled axis word in a line of gcode an error is raised.
Works for MDI and Gcode programs.

Thanks a lot for trying that Andy. I'll compile your correction this evening. I will probably have to put the 2.8.2 SSD back in the machine, and I can also see if this works there without error.

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