kcjengr.github.io/probe_basic/machine_config.html

Follow the docs exactly and you will have no errors..

This is telling you your error

"raise IOError('The specified POSTGUI_HALFILE does not exist: %s' %
OSError: The specified POSTGUI_HALFILE does not exist: /home/cnc/linuxcnc/configs/Fräse_Probe/custom_postgui.hal
1550"

Remove it from your ini hal section call. You can only have one post gui hal file and it must be the supplied probe basic postgui halfile

I think this is the goal.

Can you plot the signals:

x-pos-cmd
x-pos-fb
x-output

(with HalScope)

when you start LinuxCNC?

This will help to debug the issue.


 

Hi everyone,
thanks in advance for your help.
We tried a few things again today, but unfortunately the axes start moving immediately when the machine is enabled.
We tried creating a new HAL with the Mesact tool to compare the programming.
Unfortunately, we weren't successful again.
Can someone help me and tell me exactly what's wrong and how to fix it? It all worked before; there's also a video about it in this thread.

Almost got my pullmax component ready to test...
Wait... something is wrong. I have my pullmax component reading outputs from the GUI, then it is activating spool solenoids to enable operation in the correct direction, and commanding joint.nn.posthome-cmd a position. We can't home the ram in this configuration. Attached a drawing of what the config looks like. The pullmax component does not know if/when to activate the spool valves when homing is in progress. I have that part of it too high in the control loop.

I considered just giving it a pin to also monitor the homing state and joint.nn.motor-pos-cmd but pretty soon I will have a bunch of spaggetti code.

I think I will split my pullmax component into two components:

component press-state will be the press-brake state machine

component pullmax-optima will go between joint.nn.motor-pos-cmd and the position-pid.command, allowing it to monitor the polarity of the command (and probably also the footpedal) to set the direction command at the spool valves, while the PIDs will continue to command the proportional valves.

Looks like you have a very simple VFD/Spindle setup. If you are using a simple spindle setup that may be enough. If you have a machine with any type of gear ration between the motor and spindle the following may be of use.I'm using RS485 VFD to control the spindle on three different machines:

• Router - high speed spindle 24000 RPM with a CommanderSK VFD (capable of 1000hz).
• Mill - Six pulley combinations connected to nominal 1725 RPM @ 60 hz motor with a GS2 VFD. [MANUAL BELT CHANGE]
• Lathe - Six pulley combinations connected to nominal 1750 RPM @ 60 hz motor with a CommanderSK VFD. [MANUAL BELT CHANGE]
  
  With the Router I don't have to worry about gearing changes (or sending commands greater than the VFD can handle). 
  
  
  
  With the Mill and Lathe, I only recently figured out a way to easily change scaling to match the gearing using pid FF0.
   
  
  
  Using PID component is nice for several reasons:
  1. I can use the gmoccapy/Calibration to change/test/save [SPINDLE_0]FF0 while running linuxcnc whenever I change belts.
  2. I can set [SPINDLE_0]MAX_OUTPUT to avoid sending illegal RPM commands to the VFD which get ignored and can cause a crash if you aren't checking the at-speed status.I added a [SPINDLE_0]MAXIMUM_MOTOR_RPM parameter to the .ini and kick off a message to change belt if the motor RPM is maxed out.  
     
     Here are my additions to Mill.ini for this implementation:
     Mill.ini
     
     
     Code:

     [DISPLAY] MESSAGE_BOLDTEXT = NONE MESSAGE_TEXT = VFD using maximum motor RPM. MESSAGE_TYPE = okdialog MESSAGE_PINNAME = VFD-max-motor-rpm [SPINDLE_0] P = 0 I = 0 D = 0 FF0 = 1.135 [code]MAX_OUTPUT = 1799
     [/code]

In the near future I intend to redo my spindle encoders and use the  forum.linuxcnc.org/47-hal-examples/27071-automatic-spindle-gea idea to automatically choose FF0.

Juste quelque mA. Par exemple depuis 5V avec 1,5 kOhm en série.
Continuons  si nécessaire dans  forum.linuxcnc.org/46-francais

Robert

Ahhh thank you, I completely missed the G0 missing from the line after g33.1

You need to 'cancel' G33.1,  a G0 or G1 on the next line will help

Hello Guys!

Finally I have some updates !
The linear scales are working! Note to my selfe: dont trust anyone in the internet. 
I will make a sheet, where I will draw up the connection between the exe and the mesacard. Next on the list are the endswiches and the e stop. Hopefully it will move on its own by the end of the week. 

Here a pictue of the conector of the exe:
 

My soft limits are not working all the time. Machine is running over them to hard limit switch. When I back off machine from hard limit switch soft limit will work until next startup.

I will read through it and will certainly have questions, which I will then ask here.
Thanks in advance.
Best regards, Mücke 

@Hakan:

I would always home using the encoder index (Z-pulse) if it’s available, since it’s the most accurate and repeatable method. When the index is latched close to the encoder or in the drive, homing accuracy is essentially independent of fieldbus or servo latency. I use it with the Probe Basic and it works perfect

You are absolutly right! For probing, the usual and sensible approach is a two-step process:

Fast search pass to find the edge
Even with e.g. 3-4 servo cycles of delay (≈4 ms), probing can be much faster than often assumed.
If you allow 1 mm total overtravel, including braking, and assume a realistic probing deceleration of about 1000 mm/s², the maximum safe speed is still around 40 mm/s ≈ 2450 mm/min.

Slow precision pass
After backing off, the second pass is done very slowly, typically 0.5–1 mm/s.
With a 4 ms delay, this corresponds to only 2–4 µm of additional travel due to latency. At that point, accuracy is dominated by machine repeatability and machine stiffness, not bus or servo delay.

So in short:
Homing: use encoder index --> highest accuracy, latency-independent
Probing: fast find + slow precision pass --> latency is not a practical limitation if speeds are chosen sensibly

Latency really only becomes an issue if someone tries to do single-pass, high-speed precision probing, which is not standard practice anyway.