Advanced Search

These are my HAL and INI files     
I can ping 10.10.10.10 but every time it goes over 0.500 ms it throws the error 
These are my W2 and W3 jumpers
This is power to the board 
This is the power supply to the board 
And I also have a Meanwell MDR 60 24 for testing its just a really old one. 

+1

I have wished for a possibility to op-out of this automatic resetting to G54 on M2/M30 several times in the past.

This is why I suggested using an external 5V supply
(shorting an external supply would not affect the PC)

Hello guys,

I did some further testing of the modified EL5021 terminal. As expected, when a 120-ohm resistor is added to each channel, it is indeed able to read 1V_pp sensors again. I confirmed this with a Baumer OG73 S SN1024 (SEW branded). So, it was time to get the EL5021 integrated into LinuxCNC. For this, I used my Claude subscription and pretty quickly got a working driver for the encoder input terminal. As far as I can tell, there are no bugs in the driver. Unlike the EL5101 and EP5101, the EL5021 doesn't have the option to reset its counter with every C pulse (at least with the revision that I have - HW: 08; SW: 05). I also found out that Beckhoff seems to have made a major revision change with the newer terminals. A lot of the documented Data Objects from the Beckhoff Information System are not implemented in my terminal.

The only thing left to do is to write a component that takes care of the Beckhoff Latch-C and Latch-C-valid signals and makes them as easy as possible to use for the standard homing procedure of LinuxCNC.

Wish you all a nice Sunday

I suspect the MPG has a defective output and causing a short to 5V supply, that in turn causes the 7i77 to error out. Or it draws to much current maybe?

Thank you for help.

I preffer:

Default value AUTOMATIC_G54 = TRUE
 

Live execution of a Bambu 3D printer!!!

Actually, A neat way of dealing with this could be adding a new parameter (5391?) and modify the code so that if it was set to true, the original 2.7 buggy behaivour was restored eg
if settings->parameters[5391] == 0.0{
    settings->origin_index = 1;
    settings->parameters[5220] = 1.0;
}

Be worth playing with that.

 

Pretty sure you would just comment out these two lines
github.com/LinuxCNC/linuxcnc/blob/master...erp_convert.cc#L5177
// settings->origin_index = 1;
// settings->parameters[5220] = 1.0;

1 = G54 so this is where the reset is happening
parameters like 5220 are described here linuxcnc.org/docs/html/gcode/overview.ht...:numbered-parameters

Seems this G54 reset occurs in Interp::convert_stop()
in interp_convert.cc
github.com/LinuxCNC/linuxcnc/blob/master...erp_convert.cc#L5052
edit at your own risk

Note this is where Gcode is converted to blocks that are stored in a circular buffer and subsequently executed by motion.

I'm a bit confused, Initiially an IP address was not set but in later ip a dumps it was correctly set for a Mesa board at 10.10.10.10, It was never made clear after that if the Mesa board was pingable. I assumed it was. 
I would like to see the Hal and ini files to confirm the MESA IP address.
Can you ping the card?

Also from photos of the board, it would be great if PCW could confirm that the links are set for the 10.10.10.10 address is set correctly. W2 down, W3 Up

Also, need to check out the 5 volt power supply to the board which is usually powered form field power which seems to be the case. But are the links set correctly to send 5 volts to the logic side? Can PCW confirm?

The final thing to check on physical wiring, What is the field power voltage? What is the actual power supply? What is the power supply current available? There have been numerous instances where borderline power supplies cause network failure with Mesa cards. This must be ruled out. If need be get a good industrial power supply such as Meanwell MDR-60-24.

It might be worth setting the IP address back to automatic (DHCP) and connecting the PC to your normal network using this NIC card to confirm networking is working.

I mentioned it before but be sure to set the IP address and coalescing as shown in man hm2_eth (use your IP address and 
linuxcnc.org/docs/stable/html/man/man9/h...h%20static%20address

So if all of that checks out and a new network cable does not fix things AND the network is connecting but drops out every 45 seconds or gets error finishing read., there will likely be one of several power saving settings kicking in periodically.





 

M2 and M30 commands have the following effects:

• Origin offsets are set to the default (like G54).

linuxcnc.org/docs/devel/html/gcode/m-code.html#mcode:m2-m30

In LCNC 2.7 it fortunately did not work.
In LCNC 2.9 it UNfortunately works.

My friends used LCNC 2.7.  They used G54 for vise number 1 G55 for vise number 2 and so on. They dont use G5X in ngc files. They have many many ngc files. They were happy.

They started use Mesa cards 7i96s so they had to upgrade to LCNC 2.9. But in LCNC 2.9 automatic Ǵ54 UNfortunately works again. It is very dangerous for them. They works on vise number 2 with active G55, but after program end G54 is activated.

I need help. Where is "automatic Ǵ54 after M2/M30" in source code? I want delete it for us using.

If you are not overloading the 5V supply on the 6I25
I really don't see how any wiring or data issues can
crash the host PC.

That is, this really has nothing to do with differential
encoders at all.

I'm beginning to wonder if this is not a parity error or similar
either in the host PC or PCIE interface

Did you say the you only got the error when you changed the MPG position?

Another thing to try:
-set the Mesa encoder inputs to "single ended" for that channel (see manual)
-Wire only +5V and GND-
-wire only A+ and B+ from MPG to Mesa A+ and B+
-test
-wire only A- and B- to Mesa A- and B-
-test
?

Do you have any normal encoder, or a servo motor with encoder attached to it?
If yes, wire it and test, see if the same thing happens.
Do you have the spec for the MPG?