Advanced Search

I think there are square brackets required
#<value> = [30 * #<factor>]


setting to read values from ini file

[RS274NGC]
INI_VARS = 1 

There is a difference versus the doc linuxcnc.org/docs/html/gcode/o-code.html#ocode:subroutines
Use o100-style instead of o<mytest2>?
o100 sub
     g-code
o100 endsub

INDEX+ input (encoder disconnected)
changes the state of the hal index pin (hm2_7i80.0.encoder.00.input-index for X)

No it does not change in HAL-Show, it stays high (yellow) even if I short ENCX0 with GND (PIN on the 7i33)

Not sure what you mean here, to me you seem to be saying  hm2_7i80.0.encoder.00.input-index changes
when you ground the INDEX+ pin but then it does not change.


 

All;

I'm running LCNC 2.9.4 upgraded from a 2.9.3 disc image install.

I have this simple test script:

o<mytest2> sub
    #<factor> = 1
    o100 if [#<_metric>]
        #<factor> = 25.4
    o100 endif

    #<value> = 30 * #<factor>

    (LOGOPEN,mytest.txt)
    (LOG, factor: #<factor>)
    (LOG, value:  #<value>)
    (LOGCLOSE)
o<mytest2> endsub

in my nc_files directory. If I comment out the two lines with "value" in then the script runs fine in both sim.axis and sim.axis_mm profiles.  When I uncomment the lines I get this output:

emc/task/emctask.cc 68: interp_error: Bad character '*' used
Bad character '*' used

According to the documentation "*" is the multiplication operator.  Anyone else experiencing this issue? Is there a resolution?

The second issue is closely related. 

I also have this test script:

o<mytest2> sub
    #<factor> = 1
    o100 if [#<_metric>]
        #<factor> = 25.4
    o100 endif

    (LOGOPEN,mytest.txt)
    (LOG, laser-offset-x: #<_ini[LASER]laser-offset-x>)
    (LOG, laser-offset-y: #<_ini[LASER]laser-offset-y>)
    (LOG, park-offset:     #<_ini[PARK]park-offset>)
    (LOG, z-offset:          #<_ini[PROBE]z-offset>)
    (LOGCLOSE)
o<mytest2> endsub

where I try to read ini parameters defined in the axis.ini and axis_mm.ini files as follows:

[LASER]
laser-offset-x = -3.1702
laser-offset-y = 0.0568

[PARK]
park-offset = 0.125

[PROBE]
z-offset = 0.543

When the script is executed the output looks like this:

LOGOPEN(mytest.txt) -> 0x55cc4c8cee20
LOG( laser-offset-x: ######)
LOG( laser-offset-y: ######)
LOG( park-offset:     ######)
LOG( z-offset:          ######)
LOGCLOSE()

Again, is anyone else experiencing this issue in 2.9.4? Is there a resolution?

Kind regards

INDEX+ input (encoder disconnected)
changes the state of the hal index pin (hm2_7i80.0.encoder.00.input-index for X)

No it does not change in HAL-Show, it stays high (yellow) even if I short ENCX0 with GND (PIN on the 7i33)

And Sorry, I mixed it up- the jumpers W1-W4 are set to UP position so TTL/RS-422  sorry!
 

1. if the encoders have differential outputs, why in the 7I33 jumpered for single-ended (TTL) inputs
Answer: because I was told so   - I am really not ecperienced in these things and asked how to get the motors working and showed the schematics to experienced guys- and I was told how to wire the encoders and how to jumper the 7i33.2. Leaving the TTL option enabled, can you check that grounding the INDEX+ input (encoder disconnected)
changes the state of the hal index pin (hm2_7i80.0.encoder.00.input-index for X)

...ok, I will check this with disconnected encoder and report.

Thank you
Sigi

Hi all,Before I head to bed, I wanted to ask if anyone can quickly help me with my current frustration: getting this machine’s carousel working.I’ve got homing working, but there’s something odd—if the carousel is already homed and I try to home it again, nothing happens. I’ve managed to get M13 working, but I still need to sort out M11 and M12. I’ll attach my HAL and INI files here.I’m wondering if there are better ways to handle this, or if there are any good examples I could look at. My machine doesn’t have sensors for the pockets (which I would have preferred), so I’m working around that.Right now my biggest struggle is that I’m getting “unary” errors from my subroutine. When I try to trace the problem, the error messages aren’t very clear about what’s actually wrong. Is there a way to debug subroutines more effectively? At the moment the basic error messages don’t give me enough detail to figure it out.Any tips would be greatly appreciated

If you get probe tripped error during slow proving it's usually a sign that you might need to add the debounce component to your halfile and then recalibrate the probe in Probe Basic.

Yes shure.
I try to run servo in csp, i see one big problem - moror jumping on re-enable.

I try to dual ethercat-stepper, lol ok all enabled first motor running good - when i try to rotate shaft motor not showing feedback. second axis showing normal. first axis good run - second axis max spedd 500rpm if more motor jumping.

nvm, i found myself solution in axis/pyvcp example

Does GTK_Vismach exist, or has anyone attempted to embed Qt_Vismach into a GTK window?

andypugh wrote:

Which version of Linux, LinuxCNC and psng are you using?

I have done some work on psng to adapt it for Gtk3 / Python3 on Debian 12+
However, on my test machines, whilst it loads without errors, there are no graphics visible in the embedded tabs.

I'm curious, Why aren't people working on the version in linuxcnc?
github.com/LinuxCNC/linuxcnc/tree/master...n-panels/versa-probe

That brings up a couple questions?

1. if the encoders have differential outputs, why in the 7I33 jumpered for single-ended (TTL) inputs

2. Leaving the TTL option enabled, can you check that grounding the INDEX+ input (encoder disconnected)
changes the state of the hal index pin (hm2_7i80.0.encoder.00.input-index for X)

You should have the servo drives switched on when you start linuxcnc.
That way linuxcnc can make them go up and down as required, and change cia402 states as required.
There is an "enable" pdo you connect to joint.amp-power-on or something like that, to enable the drive.

I think what's happening when you switch on the drives is the ethercat master spots new things on the net and
scans the bus and does some setup things for the new devices. This interrupts the cyclic operation
and I would think all slaves exits op mode for a second or two, until ethercat master is ready and the slaves
can be brought up again.

So, don't switch on and off power of the drives while active in linuxcnc.

There is another method to extract the sii firmware, modify it and then flash it back. This method is permanent.