Advanced Search

I have three machines (lathe, mill, router) that I'd like to update from vfd communication (one GS2, two CommanderSK VFDs). They all work with user mode RS232/RS485 idrivers but I implemented Andy's automatic gear detection on the mill and lathe and the vfd motor speed doesn't update fast enough to track the gear ratio during acclel and decel. 

All three machines are running LCNC 2.9.8.

Lathe uses a 7i96 with 7i85S and a G540 - 7i96p1_7i85dsdi.bit
Mill uses a 7i92 with 7i85S and 7i75 daughtercards, 7i92_7i85sx1sdid.bit 
Router uses a 7i92T with a 7i75 and a G540 7i92t_g540d.bin

I believe the Mill and Lathe are custom built firmware, The router is stock. I don't sse any mention of pktuart in any of the --readhmid files?

My understanding is the 7i96 on the lathe should be RS485 compatible? Hoping this is just a firmware update?
Can I use the Mill's 7i85S RS422 with a RS485 VFD?  Ok if I need to use a TTL/RS485.
Can I use gpio with a TTL/RS485 adapter (solution for Mill and Router).


After initialization, I only need to write 2 registers and read 3 registers and I could block these up. Looks like hm2_modbus would be perfect for what I need if the hardware I have supports it.

 

yes I like that better.

Marcos wrote:

Hi Rod,

 Once you start talking about pushing the host loop into the few-hundred-microsecond range, things like DC setup, cycle stability, NIC behavior (EEE, IRQ coalescing, etc.) and jitter stop being details and become the main engineering problem. That was the point I wanted to make.

When I said Mesa tends to be more “KISS”, I meant it in an architectural sense, not as a value judgment. EtherCAT is a full industrial fieldbus: multi-vendor, DC, flexible topologies, designed for distributed systems — that’s a big strength. The hm2-eth approach is intentionally simpler and focused on talking to the card, with the time-critical I/O timing living in the FPGA. Different tools, different trade-offs.
 

EEE, IRQ etc are really at the operating system level so they effect networking for both Ethercat and Mesa. But I think Ethercat is less affected.

In the RT community, the need to optimize/tune the kernel is well understood. Here at LinuxCNC we have only just been forced to come to grips with this since we adopted Bookworm. We skipped deployments on Bullseye but let me assure you the issues were there then.  I agree that users should never need to understand how to apply these settings, it should be done for them. Yesterday, I delivered a custom Linuxcnc installer that sets the system up for optimal RT performance in a networked environment and installs and configures ethercat. The customer just needs to install his linuxcnc config. Ultimately, I will build a more generic installer but I have to first recover from the brain-hurt this project inflicted on me!

Before i say "Looks awesome", i have to say: those slider buttons look really nice, so why is the jog slider still looking dull?
Now i can say: Looks awesome!

open a terminal and type in:

editvcp probe_basic

it will open the editor so you can see the properties. here is an image of them for reference:

 

 



Follow the sim hal and postgui hal to see the connections. note the pinbasename properties for the in gui button and the led and how the connections flow in postgui hal:

# *** Probe graphic simulation trigger push probe tip ***
net probe-in  =>  qtpyvcp.probe-in.out
net probe-in  <=  qtpyvcp.probe-led.on

those wires look too long and too loose. you will need to shorten them for sure and tighten them up a big
shorter is better, keep it as short as possible
edit do you mean 8inches and not 8cm? 8cm is the length of the rpi board

Would you prefer it like that?

ihavenofish wrote:

I have multiple threads on these things, with files posted
 

Thanks, I will search...

@Marcos DC
I assume my best chance of diagnosing the behavior is to start with identical hardware and configuration.

I do not know enough details about ihavenofish's issues to point at any specific bit at the moment. I suspect some unexpected interaction between the Omron drives and the LinuxCNC CIA402 component but that is just conjecture at this point. I would like to take a closer look at CIA402 component behavior while running real hardware on my workbench.

Marcos wrote:

@NWE


I know this thread is about EtherCAT motion control in general, so to avoid derailing it, maybe it makes sense to open a separate thread focused on this specific Omron / CiA402 / startup behavior case, where we can look at the actual component, configuration and state machine logic in detail

 

I have multiple threads on these things, with files posted
The point of commenting here was to say that ethercat in linuxcnc can be a little flakey here and there, but still the way forward.

NWE wrote:

ihavenofish wrote:

--snip--
I don't know if that's a linuxcnc thing, and ethercat thing, or just a stupid omron thing.

Other than these quirks though, its great and I would not switch back for anything haha.
What model number Omron drive is this? Also, are you using some form of CIA402 component with it? Which one?

I have had a keen interest in Omron servos for a while, but never actually worked with one of those. One of my upcoming projects could use one, now knowing there is "some mysterious bug" of sorts really catches my interest. If I manage to carve out some time for this, I would like to acquire the hardware and investigate the problem.
 

I don't think any of my issues are anything to do with the omron drives. I know 100% the first one is explicitly a conflict between ethercat and modbus naming and start up synchronisation. it is basically reinitialising the drive over and over and over The question is.. WHY?

The new one about joint errors/limits just showed up at random and went away. I think it was related to some stored values that got cleared on reboot, but not simply on linuxcnc restart. Like is was storing the wrong home or last encoder position etc. (i had shut down linuxcnc and rebooted the drives, then restarted linuxcnc). Probably an edge case that likely will never show up again.

The ffirst one is more important, cause every 10 times or so it starts it wigs out.
 

 

Whoops, got the wrong image. It's a 7i96s

You can figure it out via the 7I85 manual but more easily with:

mesaflash --device 7i92t --addr [card_ip_address] --dbname1 7i85 --readhmid

Do you have a Mesa 7i96 or 7i96S?
Your tittle says 7i96S but the attached picture is for 7i96, so what gives?