Advanced Search

Same as FMD config but 7I52 on P4:

 

 

I would disable "auto volts" and in the settings tab set the VAD to 60 or 65%.

OK, that makes sense. I did set up my 7i80 which happened to have a config on that looked similar enough to try, but it also didn't want to talk to the 7i84 - that could just be that it wasn't relevant for the 7i52 though.

I'll try out the pin health tests tomorrow when I'm back in. I think I have the means to make up another couple of cables that I can swap out, so I can rule that out.

I also thought of moving the 7i52 to P4 - it's unused in this setup - please, could you make me a firmware for that arrangement? The firmware in question, in case this helps you, is the one you made for me following this thread: forum.linuxcnc.org/27-driver-boards/5075...ware?start=10#286332 which has been working well up until the last couple of weeks. This would allow me to keep using the 5i23 which would be optimal.

Thank you for your support.

Kind regards,
Andy

Here are the screenshots. Google only returns LinuxCNC when I search for "cnc Linux" with quotes. I was thinking maybe that was the project name before it was EMC, but I figured you would know

This should be close:

 

My guess is that either the 7I52 cable or 5I23 pin P3.45
is bad. Pins at the end of the flat cables tend to be the ones
that break  first and also those are the pins that connect first
/disconnect last when cables are plugged/unplugged (which
presents an ESD and voltage differential hazard)

A quick check of the I/O pin health is to power down everything,
remove the flat cables and run this test:

sudo mesaflash --device 5i23 --rpo 0x1000   # P2
sudo mesaflash --device 5i23 --rpo 0x1004   # P3
sudo mesaflash --device 5i23 --rpo 0x1008   # P4

You should expect a result of 0x00ffffff in each case

If there is a bad pin on the 5I23s P3, another possible fix
is to move the 7I52 to P4 (and make firmware for that arrangement)

With R2=1k & 10nF Vgate is 364mV (is not exactly the same in all 3 pcbs maybe due to different electric characteristics of zeners )
I have done 2 changes put 1uF multilayer cap parallel to 10nF cap
and put another 1k parallel to R2 so R2 now is 500R and Vgate reduced 250mV (with tic106 triac).
Also connected shield to ground this was the critical fix because the fuses burned when the servo drives enabled
and emf emited from servos maybe trigger the triac.
Now does not burn 0.5a fuses and system works perfect.

I think that i will remove the protection circuit with triac and use protection with p mosfet.

16x interpolation is SF0=high SF1=high ENCODER_SCALE=3200 ?

Tests with 5v supply:
5v1 zener 1k resistor -> 351mV
5v1 zener 470R resistor -> 240mV
5v6 zener 1k resistor -> 101mV
5v6 zener 470R resistor -> 55mV
 

I think I saw the drawing for the resistor in the Plasma primer but Ive seen two versions of it with different resistors in place.

RDA wrote:

As for some benchmarks maybe you can check out this:
LAN9252 SOES
Check a few posts later where he also benchmarks the AX58100.

I know this is not really the same as the topic but I found it pretty interesting.
 
 

I saw that, probably just glanced over it cuz it's alot of information and it's a bit hard to figure out what he's actually saying. His chart shows that using his own SPI driver (called SPL) that uses STM32 standard peripherals is much faster than the Arduino based SPI library. In his notes he doesn't really say that, he just talks about SOES itself. The last line in that chart doesn't look too much slower than the AX5100 stuff but it's much faster than the Arduino benchmark with the same STM32

I see it looks like Hakan is using Arduino, maybe that's an issue?

Ok this may have been the problem I have with the material list. I looked in SheetCam and I had many other then plasma tools that showed very high tool number. I will rerun the tool conversion in the morning with only Plasma tools.

Back again with new problems,  some time I get good cuts and other time not at all.
First thing when starting up I get a material error see attached.
 
I can cut a straight line (7") no problem,  Add shapes to a cut and either stops about 1/3 the way through, or may crash the torch into the metal.
Today after a crash it gave my the restart option, I moved the torch a small amount for restart off the path.  The cycle resume button was flashing, when I pushed it the torch moves down touched the metal and retracted.  And I get a message about the probe.
 
 
I can run without the torch without error with multi-part G-code.
Just did an update/upgrade to V2.10-005.033 do not know if this will help with the problems I am having.

rodw wrote:

blazini36 wrote:

I'm not really concerned with why Beckhoff uses Intel NICs, there's about a million reasons that that could be the case and none of it necessarily has anything to do with whether any other NICs work fine or not. Likely has to do mostly with validation and some financial exclusivity agreement. Only problems I've encountered with RealTek NICs and Mesa cards were always resolved with drivers or bios updates.

 
Maybe I should have prefaced that this was conveyed to me by Beckhoff staff when at an Ethercat seminar in Australia where Martin Rosten from Germany,  the Head of the ETG spoke. At the time, I mentioned that we had network latency issues with some hardware on Linuxcnc. The reason Beckhof uses Realtek is technical, not commercial.  Fortunately, Ethercat is a more efficient protocol so less likely to be an issue.

The network latency issue was introduced to the Linux kernel with Bullseye and has never been fully resolved out of the box. IRQ pinning is the most effective method but BIOS, dkms drivers (only from Bookworm and up) and using a kernel compiled from pristine sources all help.
If Hakan is using the 4.19 kernel, it is to avoid the network latency issue and other so called "improvements" to the 5.9 and up kernel.....
 

Probably going off the deep end a bit with the NIC thing. He's @ 2ms with an Intel NIC, so no idea what issue he's having with the Realtek but it likely has nothing to do with this....maybe just a troubleshooting step. I don't really recall the gist of your whole latency discussion but when I had issues with Realtek it was resolved by upgrading the BIOS on an H3 so that's a Hardkernel issue, not a Realtek issue. I haven't had any issues with Mesa cards @ 1ms on Realteks otherwise. I'm not running custom kernels, they're definitely newer than 4.19, but I'm not doing deep dives either cuz when stuff works I just leave it. So the 2ms thing is likely making up for something else.

Get something like netplus.com.au/products/usb-wifi-adapter...ith-external-antenna
and a SM4 bulkhead cable (get the connectors right). Then you can relocate the antenna to the exterior. DOne this a few times now.

I still want to get wifi and bluetooth working in 6.1 Kernel they work in 6.6 kernel but not sure if ill run into latency issues like i did in 6.5kernel. But yes when I have wifi working the reception is cut in half when the cabinet door is closed.

Set the thcad2 to use a 5 volt range and it is all still applicable.

Forget calculators. We let hal do the calculations.
I've attached a later version with a seperate hal file you can add to your ini.
This requires an additional resisotor if on a water table. I can't share that as I don't have access to Google Drive from here.