Advanced Search

Hi all,I think the real challenge here is not “making it work for A6” or for any single brand, but making it work generically for any CiA-402 EtherCAT drive — including the obscure or poorly documented ones.I don’t have this hardware on my bench, but I went through the documentation for Yaskawa EtherCAT drives and also some of the available documentation for A6/Lichuan, plus the CiA-402 profile itself. From that, it’s clear that while they all follow CiA-402 at the structural level (6040h, 6041h, modes, state machine), the details around homing status and mode-specific bits can vary quite a lot between vendors.CiA-402 defines the structure, but it does not guarantee that every drive exposes a clean, well-documented “homing started / in progress / done” set of bits, or that bits like “target reached” behave identically across vendors. Two drives can both be “CiA-402 compliant” and still differ significantly in these details.That’s why Andrax’s point about watchdogs and state checks is important, even if the exact bit numbers vary by drive. The idea is not to rely on one vendor-specific flag, but to build a defensive, generic state machine on the LinuxCNC side:

• switch to homing mode and confirm via mode display,
• issue the start command,
• verify that something actually changes within a timeout (state, target reached, position, etc.),
• wait for a generic completion condition (e.g. target reached / mode change / no fault),
• and always have timeouts and fault paths.

Looking at the currentlogic, it seems to focus mainly on “start homing” and “target reached”, but without explicit timeouts or richer state validation. That may work for some drives, but for a truly generic solution (including obscure ones) it probably needs to be more defensive and timeout-driven, rather than assuming specific bit semantics.So from my point of view, the goal should be to keep this LinuxCNC-centred, but design the homing logic in a way that does not depend on vendor-specific interpretations of CiA-402, and instead survives the worst-case implementations by using state transitions, minimal guaranteed signals, and watchdogs.(This is based on documentation only, I don’t have this hardware on my bench.)

Run the simulator to ensure your installation is good, if so, compare its configuration files to your machine config. You'll be able to find where your errors are coming from between that and the docs

 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.

Upload the hal and ini files here.

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
     
     

     [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.

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.