Advanced Search

I am a beginner in linuxcnc ethercat I am waiting for your help
.4 Chinese drivers work without any problems in the same system operating modeLs servo ????? op problemsethercat slaves    ?????????
 I couldn't find the reason why it was switching to op mode and not switching to it.I am adding demesg and other outputs that you can askI couldn't find the reason for this, I would be very happy if you could help me. I bought 10 of these servo motors, but I couldn't solve the problem of whether it was connected or not.

cnc@debian:~$ ethercat slaves
0  0:0  PREOP  E  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
1  0:1  OP     +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
2  0:2  OP     +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
cnc@debian:~$ ethercat slaves
0  0:0  OP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
1  0:1  OP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
2  0:2  OP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
cnc@debian:~$ ethercat slaves
0  0:0  PREOP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
1  0:1  OP     +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
2  0:2  OP     +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
cnc@debian:~$ ethercat slaves
0  0:0  OP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
1  0:1  OP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
2  0:2  OP  +  L7NH - Standard EtherCAT drive(CoE,EoE,FoE)
cnc@debian:~$ 
 

I tried to enter the estop from tuxcnc above and got this error.

I attached my hal and ini files. Does this mean I can only have the watchdog or the estop latch but not both?

*Edit*
I have just tried the estop latch with the tuxcnc code with the watchdog commented out and after fixing the typo in the last line where it starts out - net remote-estp ... - it is missing the o in estop. That error is in the attached hal, didn't catch it befor attaching. It works, exactly one time, by opening the circuit and thats all she wrote. reconnecting the circuit and can not reset the estop and power back on the machine without closing down and restarting the gui.

Thank you for your answer.

The tool length transfer also works with G43 and is also applied to the loaded tool after a change in the tool table. However, the tool diameter is not transferred. The data is only transferred when explicitly unloading or when switching to another tool and then back to the changed tool using the M61 Q? button. Unfortunately, only M61 Q? doesn't work because I get a message saying the tool is already in the spindle.
Can I somehow initiate the diameter change?

I think I have a different understanding of tool length. Fundamentally, machining can only be performed with a measured tool with a specific length. Therefore, tool length compensation should always be active. Which is why I can't understand why there is a G49 in the "on_abort" subroutine. If I have to abort the program, the tool length is set to 0, which leads to errors when calling the program again if there is no explicit G43 in the program. I removed the G49 from the "on_abort" macro program.
So, for me, the tool length should always be active.

Thank you cakeslob for these posts. I went back and read the Remona manual again from the start and I did discover something I didn't know before and that is the included estop stuff at the beginning of the sample .hal is a coms watchdog and testing it by unplugging the ethernet cable triggers the estop. Shiny, I can understand the function of that part. How or why, cluless, but what it does is clear.

But you asked if there were any questions, and yes there are.

I'll start with a single line from the tuxcnc example above.

1. estop-loopout - where did that come from? Did a search "estop-loopout" site:https://linuxcnc.org/docs and got 0 returns, same with a search of the Remora doc site, 0 results.

2. estop-latch - this did return some results - linuxcnc.org/docs/html/man/man9/estop_latch.9.html but I do not see any connection there that would lead me to come up with those words being placed where they are in the example. How would one know to put that there?

3. <= and => - What do these mean? Do they denote the direction flow of data or signals, do they stand for less than and equal to and equal to and greater than or is it something else and why are they needed and what determines where they go? Is this explained somewhere?

To be truthful, maybe I should be looking for someone to hire that can do all this complex coding and programing for me as it seems far and beyond my ability with my learning handicap.

For the moment, I'll keep trying and hack away at it bit by bit. To much time invested to round file it all now, but please feel free to tell me to go pound sand when I become to much of a burden. I won't feel bad, happens all the time when I am confronted with this kind of complex programing.

Hi everyone, I've started to experiment with Ethercat and Beckhoff modules along with LinuxCNC. I have to say that it was easy to use the generic driver and get up and running. I've used some input/output modules, encoders, and analog outputs, for example the 2809, 1809, 5151, and 4032.
I was thinking about using modules with PWM outputs, and to my surprise, I saw that they are not included in the drivers (correct me if I'm wrong). I could try coding a specific driver, for example, for the 2502 and 2535 modules. Although if someone has already done it, perhaps it could save me some time.
The truth is that being able to use Beckhoff industrial modules with LinuxCNC has great hardware advantages, as interfacing with servo amplifiers, encoders, etc. is very simple. I've done some things with Remora and the RT1052 firmware, in which I've developed some encoder and PWM modules, but I always run into interface problems, especially with industrial modules. Obviously, compared to Beckhoff, this solution is much more economical.
Well, I hope for some answers, guys, about the EL2502 and EL2535 PWM modules. If anyone has developed something and wants to share it, I'd appreciate it in advance. Best regards.

If the homing direct does not change, then it's likely the you did not
change the correct ini constant (or perhaps there is another error in
the ini file homing constants or perhaps home switch operation)

I don't think you can eliminate the soft limits issue unless you get the
MIN_LIMIT and MAX_LIMIT setup properly (MIN_LIMIT < MAX_LIMIT)

It may also be the you have the hardware directions reversed, this you can
fix by inverting the direction pin or changing the sign of the joint SCALE
ini constant. (say 4000 to -4000)

Working like a charm.
Thank you very much Peter!

P.S.
Damn self-made DB25 cables. Firmware initially didn't make any difference. Apparently cables on P1 and P2 were backward. Reversed both DB25 connectors and now I see both 7I76 and 7I89 and encoders are working. These Mesa cards seem to be very robust, even all wrong signals on all the wrong pins didn't make them go dead.

paste your compiler error, I will make a suggestion that might get me shot, but Chat Gpt4o has been trained on the linuxcnc halcompile syntax, you have to bully it a bit to get it moving but it can help you debug, but share the compiler output I'll see what i can do to help.

7I76EU firmware with 7I76 on P1 and 7I89 on P2

 

Each connector is independent, though module channels may differ between firmwares
Note on the 7I89, you may need to turn on Encoder power (depending on jumpering) and it
also requires  both cable  _and_ external 5V supply to P1.

PCW wrote:

Wrong firmware, 7i76eu_7i76x1_7i88_7i89d.bin is for a 7I76EU +7I88 (P1) + 7I89 (P2)

I'll take a look at making a config for a 7I76 (P1) and 7I89 (P2), but probably tommorow...
 

Would it be 7I76U (with sink/source I/O option and spindle/encoder interface) on P1 and 7I89 on P2?
Also, 7i76eu_7i76x1_7i88_7i89d.bin has 7I89 on P2. Should 7I89 on P2 work even if 7I76 on P1 doesn't? Or P1 and P2 handling is interdependent?

Wrong firmware, 7i76eu_7i76x1_7i88_7i89d.bin is for a 7I76EU +7I88 (P1) + 7I89 (P2)

I'll take a look at making a config for a 7I76 (P1) and 7I89 (P2), but probably tommorow...