Advanced Search

In an older Probe_Basic version I adjusted the interface so that everything worked.

However, I don't know how to edit the interface in the stable version. I'll probably have to install the developer version again, which I don't necessarily want to do since the machine is currently in use.

However, I still have the question of why the 4th axis plot doesn't work, which used to work in the older version... my configuration has remained the same.

I do have an Kress 1050 FME-1, just manual ON/OFF (automatic via Zigbee Switch) and speed control. So the Spindle Tab in Gmoccapy is useless.
Is there any EASY way to exchange it with lets say ON/OFF Button for the Spindle?
 

ah thank you! Knowing that it's possible is helpful. I will look into it and let you know if there is something we can adjust to make it easy.

ok, IO_TYPE for cst pins are back, but only if it is set to non-default value

I have pneumatic actuator controlled by one of the digital outputs. when my machine goes into estop or external estop swtich is pressed, the system stops, but the pneumatic actuator still remains on!

i tried using the and2 examples from one of the earlier threads, but it didnt help me (or atleast i wasnt able to make the and2 logic work)

net estopwa and2.0.in0 <= halui.machine.is-on
net estopwa and2.0.in1 <= motion.digital-out-00
net parport.0.pin-07-out <= and2.0.out

- Also, as the program is resumed after the estop, i want it to run from the same line.
I have this in my ini file.
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
GCodeContinueOnEstop = True

However, if the program resumes from the same spot, and we reach a solution to turn off the pneumatic actuator on an estop event, the pneumatic actuator would remain disengaged, i want it to re-engage on the resuming of program.

Looking forward to expert help

Glad you got it sorted, I think there is a patch for linuxcnc versions after the lockdown 2.9.3 for this issue, it was discussed in a previous thread I think.

Sorry not sure on loading to soon for the Mesa. My Ethercat is still on my bench system which i then have a esp32 for doing the other step and it didnt seem to matter the order or i have not played enough to cause errors.

Hmmm, sounds like a joint numbering issue and PB UI load issue, I will need to sit down and ponder this, covering all of the various configurations is a bit tough, need to find a better method I think. Maybe have the axis drop box be a user definable box.. not sure though, will take some figuring to find a solution I think. In the interim you may need to customize your UI. Any fixes for this will be have to come in the develop version and will be a bit away, I'm a bit slammed at work right now. I will update here as I find a good solution.

MirkoCNC wrote:

I do not know why, but Tab Overview shows graphic again.
IO_TYPE is better to have back, please
 

i have fixed the overview today.

IO_TYPE, no not at the moment, have to check some things first.

@digiex_chris
i have no RPI5, so i can not test it
i only know that there is a general problem with RPI5 and SPI,
but someone on youtube got it to work with RIO

Hello i´m using the actually Probe_basic stable apt install and i have some questions....

i find a bug in the probe_basic axis view on the mainsite...

i´m using XYZB Axis but probe basic shows me XYZA

when i put on another axis like this XYZBW then probe_basic shows me XYZAB

the same on the single axis ref button i´m using a XYYZB Machine but...
X ref is ref my X Axis -> OK
Y ref is ref my Y Axis -> OK
Z ref is ref my Y Axis -> Fail
A ref and b ref i don´t know i have to try it...

the plot doesn´t show me the 4th Axis gcode...
when i turn my B Axis the plot turn the mill around my Y axis that´s ok. but when i load a 4th axis gcode the plot shows me only a 3axis gcode only the milling tool is rotating around the y axis

@meister have you done any investigation on running the iceshield on a rpi5? it seems the spi and gpio hardware is different. I am unable to get a clock signal on pin 7, it seems like it was not a well supported feature. I used an rp2040 to generate a clock signal instead, wired to pin 7, and flashed using a pi4, and have the blinking light but I'm getting EMCMOT timeouts from linuxcnc. I suspect the SPI interface is different. It's definitely there, I have the expected /dev/spidev0.1, /dev/spidev0.0 devices. I'd love to use the pi5, it's MUCH faster and has better jitter. 

I do not know why, but Tab Overview shows graphic again.
IO_TYPE is better to have back, please

I give up on the portable Python....toolchain. It is easy to use the IDE.

It would be good to have the IO_TYPE back in the pin list and the graphic in the Tab Overview

Thanks tommylight I will have to look back at his channel . Last time I checked there it mainly had stuff from 4 or so
years ago. I wasn't sure if his tutorials were going to be relevant on V1.0.

As I have no hardware yet, I am wondering if it is good decision to remove IO_TYPE completely.

It was just my mistake because I have not realized that it can be set within your tool.

The IDE shows me in the Pin Report that all pins are on LVCMOS18 now.

I