Advanced Search

whew yes the init light is blinking. I will look into what I need to do to un screw up my card and hopefully get the correct outcome this time lol

already a good starting point

github.com/multigcs/esitool

I was reading about g-code remapping again just now. M3 isn't remappable, sadly, but I found that there's an available remap for M6 ("ignore_m6") which would avoid the bug that started this thread. So that's interesting, but not long term, since I might actually want to implement tool changes.

I also found that, while M3 isn't remappable, the S comand is. So there might be a way to use that.

G1 Z0 to fool at-speed? Devious! I'll give that a try. M66 is an interesting idea too. I'll think about that.

Right now my solution is all hidden behind a perfectly normal looking M3, which is kind of nice. (Well, unless an M6 happens too quickly after the M3, as I've discovered....)

But first I have to do "just one more test carve" on a piece I want to take on vacation later this week...

ok. i think i got it. you create a bus with width of the data frame, clock the data in/out via SPI, and map each peripheral to a certain bits in the bus to use as input/output control registers. very elegant, simple and lightweight, the only inconvenience it needs driver rebuild for peripherals changes.

compared to mesa which uses memory map with peripherals mapped to addresses in the memory and need cpu parsing to read write addresses. but this allows dynamic configuration of the driver.

It wasn't missing it was dryed out during the years and pulled down the battery voltage. Thats the reason the servo amp always complained position lost. I reordered the cap already but you know how it is: Nothing is as permanent as a temporary solution

on ethernet..
Zynq 7010 has two gigabit ethernet controllers (GEMs) available for PS (ARM cores). that EBAZ board however has a single 100 Mbps PHY and magnetics. its RMII port is wired to the PL, so it can be used either with the GEM (via EMIO) or any soft core MAC/CPU/whatever implemented in PL.

Shall i continue this thread or open a new one in the right subforum for the retrofit itself ?

I'll leave that up to you.

that missing C9 is fitted with 1F/5.5V supercap on OSA104/OSA105 (absolute) encoders to keep them running for a while when the cable is disconnected. OSE do not need it

The thing is you don't have to spend hours learning new things, you can use the Mesa cards. No one has a gun at your head. I like learning new things....it keeps the Black Dog at bay.

Some of us like to tinker, build hardware and such. Like I said in my first post, it's not always the cheapest route if you're the guy doing the designing.

I've actually gotten a better understanding of the Mesa hardware by getting involved in the projects I've been pursuing.

I started using Linux pre 2000, so I've seen Linux mature and get very much more user friendly. The biggest issue back then was the bloody so called "WinModems" for dial up internet.
To tell the truth the Driver situation is far better than Windows.
Most hardware is supported via the kernel. I'll admit bleeding edge hardware is an issue, but that can be down to the manufacturers not supporting Linux, but generally it ends up being supported. Driver installation is far less intrusive.

Bought a new printer last year, connected via the network.....30 odd minutes to the windows installer to do it's thing. My Mint box saw it straight away on the network.

To be honest I'm an exclusive Linux user, the windows machine is for my Mum, but once Win10 stops receiving updates I'm going to get her using Linux.

To me it all feels like pain. With nuances, I can choose what pain I like best. headache, food, knee or back-pain or eyes.

Driver issues (Linux) not available software (Linux), planned obsolescence (M..-OS),
nuisance UI "upgrades" and activatio codes (W....ws).
Subscription software (everywhere) .....

Rule of thumb: if it uses Electricity, stay away from it. ... haha. ( instead of a fret saw I am using a 3d printer )

p.s. I almost forgot. Removing the "f.ck..g" bloat ware from a store bought Windows System takes almost as long as retrofitting god knows how many cnc machines. 

And finally a tiny video:

The xml to eeprom translation is a missing piece. With the pdos and sdos. Siitool comes halfway.
Currently I see no other option than to use TwinCAT. If there was a way for TwinCAT to only do
the translation of xml into an eeprom binary file that would help. But no, I have to take out the card
from the machine and bring it to the Windows/Twincat machine and flash the eeprom from the xml file
with TwinCAT.

If you like JavaScript, you can start from the eeprom_generator which already can do the eeprom content,
without pdos and sdos again. There is a src/generators/EEPROM.js you can have a look at.
EasyCAT uses LAN9252 I have read so should be directly usable.
github.com/MetalMusings/MyOwnEtherCATDev...ils/EEPROM_generator