G10 origin setting beating up EEPROM?

[MadTooler]

I have a 2axis closed loop system that can be moved manually when not under motor power. Since it is closed loop, I have realtime feedback via the encoders as to where it has been moved. My method for updating grblHAL as to the current position is via a G10 command. I recently discovered G10 forces writes to the EEPROM. I think the EEPROM in a pico is limited to somewhere around 100k writes, which I probably have already exceeded since I have been writing G10's at about 5hz. Surprised it is even still functioning.

Is there a better way to achieve updating grbl of coordinate changes than G10, or a non EEPROM solution?

With my system, it probably is not important to maintain the coordinate system after power down since the machine will freely move while not powered and will always need origins reset upon power up. Should I change grblHAL to use ram instead of EEPROM?

Thanks

[terjeio]

Switch to a real EEPROM (default is EEPROM emulation in flash), or even better - FRAM, there are I2C support for different sizes. Minimum 2K, 4K is more future proof. FYI FRAM can sustain near infinite write cycles.

I have been writing G10's at about 5hz. Surprised it is even still functioning.

The "EEPROM", or non-volatile storage (NVS), is only written to when in idle or alarm state. Changes are buffered in RAM when not.

Is there a better way to achieve updating grbl of coordinate changes than G10, or a non EEPROM solution?

A plugin can save to RAM, that would be the fastest method. But see above...

Should I change grblHAL to use ram instead of EEPROM?

Not neccesarily - I would go for FRAM. BTW you may take a look at the odometer plugin, this writes counters to NVS regularly.

[MadTooler]

Which board is that? The default - using the generic map?

My motion control board is custom. The rp2040 pico is a standard issue from raspberry pi with only slightly modified mapping. I don't see any FRAM in their documentation. For now, I would prefer to find a solution that uses their hardware as is.

You mean via an external UART <> USB breakout? Then I honestly do not know high you can go, I have not profiled that. If via the native USB port then the baud rate is ignored - you may get a sense of how high you can go by running a large gcode file in check mode and time how long it takes to complete. IIRC I have seen transfer rates up to around 400 KBytes/sec for the Teensy 4.1 - expect less for the Pico. Since I have a Pico running remotely , I just tested a telnet connection - and I got 46 KBytes/sec for that. Oddly the Websocket connection is faster at 75 KBytes/sec, but that could be due to sender side differences...

I only meant USB communication with the official raspberry pi basic pico. I have seen upwards of 961.6 kBaud possible since it is USB1.1, but also that there is some sort of bottleneck that results in massively uneven up/down transfer speeds. With a standard pico, is the baud rate ignored anyway?

Be sure to enable character counting mode when testing (Agressive buffering in ioSender).

I was using UGS and CNCjs for a sender since I am running on a raspberry pi 4 (if in windows I would have gone to your ioSender). Currently, I have started migrating over to running from within Node-RED. I am using Node-RED for a lot of other control features. The communication between other senders and Node-RED was becoming a major pain. Moving the advanced features of a sender, such as the visualizer and file handling, may end up being as much or more of a pain, but at least it will be all under one environment. If anyone else wants to torture themselves, I would love some help with giving Node-RED a gcode sender set of Nodes.

[terjeio]

For now, I would prefer to find a solution that uses their hardware as is.

Then you are stuck with either storing in RAM or flash.

With a standard pico, is the baud rate ignored anyway?

I guess so, unless the host side restricts the speed to the configured baud rate. IIRC there are drivers, or configs(?), that can do that.

[MadTooler]

Thanks for all the information. For the moment I am thinking I might be able to greatly reduce writes with a new approach. If it doesn't pan out, I will post back and look into moving it to RAM.

[terjeio]

I have seen upwards of 961.6 kBaud possible ...

Testing with check mode in ioSender achieved ~100 Kbytes/sec so that agrees with what you have seen.

Do you only keep the current position updated when you move motors or do you sync motion as well?

I want to be able to sync motion, e.g. when turning the spindle by hand. I have an idea for how to insert motion that bypass the planner that could be used for both rigid tapping and plasma THC. To be explored...

Edit: rigid tapping, not threading

[MadTooler]

Do you only keep the current position updated when you move motors or do you sync motion as well?

Funny you should ask. I do both at different times. I have only X and Y with an rp2040 pico running as a motor driver controller between the grblHAL rp2040 and the trinamic stepper drivers. My motor driver pico reads step/dir in and quadrature encoders. Both pico's are connected to a rpi 4b via USB/serial. At the rpi, I use Node-RED to keep things talking and handle custom features of the CNC controller.

In one scenario, I sync one motor under power to the other that is freely being moved by using the encoder feedback to directly step/dir out, which correctly positions the other with no calculations being done for acceleration. This works very well except if the operator moves faster than the top speed of the stepper under power (real servos would work better at the top speeds but I cannot fit them into my project). In the other scenario, both axis are free to move while grblHAL is updated as needed to the new positions of both.