Advanced Search

Oh there must be so much to change i just didnt see the other slider

Thanks a lot guys your awsome!

Hallo zusammen , ich habe eine mesa config mit einer 7i97t =>7i74 und an der 7i74 hängt eine 7i73 und 7i84  nun hab ich gestern ca 5 stunden lang versucht die 7i73 in den mode 1 ( encoder+analog in ) zu bekommen das hat nicht funktioniert ich habe das mit dem ändern von  sserial_0=0100 versucht und verschiedenste Foren Beiträge gelesen bin aber zu keinem Ergebnis gekommen eventuell weiß ja wer von euch mehr oder wie gehe ich da vor ? Wenn ich in das terminal eingebe Halcmd show pin  dann werden mir die Pins so angezeigt = hm2_ 7i97.0.7i73.0.7.input00 beispielsweise . Die config läuft aber ich weiß nicht wo der Fehler ist oder was ich anders machen muss damit das funktioniert . Gruß Tom 

Danke schonmal für die tollen Antworten,  ich werde das heute mal anwenden und berichten über das ergebnis , ich hoffe es klappt . Gruß Tom  

wheeeee

According to the manual, a 24V switching power supply must be used for power.

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 during acclel and decel. 

All three machines are running LCNC 2.9.8.

Lathe uses a 7i96 with 7i95S 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 intialization, 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.