Phil the top of the spring is held by a 1/4" cap screw where a hole on each side were the same height so it made it easy to hook up   Now to adjust the spring all I need to do is drill/tap more holes for different spring setting.

Ok found the first problem with claudes code as I have the controls set to 75 and the code goes upto 79. So changed the gui controls to 80 and uploaded again.



Now I did try commenting out OPTION EXPLICIT but the same error comes up so it does look like SURGRIND isn't declared so whats the correct way to get this done please as the grey cells are calling for more caffine.

OK after some caffine intake I put in



Then got to the next error where the VAR SAVE was over 3 lines so had to put the VAR SAVE SurGrind, on the lower 2 lines  

No errors so now I can have a play and the page 7 run screen does look nice  

One thing I have noticed is the position display box's aren't being filled and I'm sure this SUB




is the problem as one of the errors was SurGrind wasn't declared so I did declare SurGrind as Float and after doing the var save on the lower 2 lines got no errors but it does seem the the var restore isn't working.



So not sure what is going on

Hi Bryan1,
VAR SAVE is writing to Flash. Not sure how long it would take to wear it out at the rate you are thinking of writing. This I2C RAM chip may be useful.
Search 47LS04 is the forum where a few have used it, see Jim's post below for details on using it.

An alternative to VAR SAVE 47LS04

Gerry I do have a heap of old microchip 24AA eeproms here so we could use one of them as I am considering making a new driver board where the breakouts can be spaced 5.08mm so standard connectors can be used.

Now this eeprom can sit nice and close to the pico 2 so no interference is there and got plenty to share with Lyle  

Another option, if a RTC module is being used, is the 24C32 I2C EEPROM chip that most RTCs are fitted with. It can store 4096 bytes in 128 32 byte pages.

Ok I decided to try out Lyle 005 code and did a stepper status




Now this is the one with claudes code



As the position display won't work may just have to go back to the 005 code and expand that and use the claude example to learn from.

now page 7 does invoke the run and the Z axis does step 0.05mm but as we haven't done the code for the buffer yet the run code will do nothing.

As the numberbox isn't setup with a decimal point the input can't be less than 1 where on the Z axis we want 0.05 or there abouts.

I do think I need to make a new page where one can put in the data so the output can go to the buffer, now I can make the page easily but as far as getting to to work will take a long time to understand.
Edited 2026-06-01 16:22 by Bryan1

The 47LS04 is an EERAM, so no limitation on the number of writes. It can be set to automatically save and restore to/from its own internal EEPROM so it keeps the data  during any power interruptions.

Googling the 47LS04 and it's a hex inverter not a ram chip

Now this is the datsheet for the 24AA1025's I have here and they can do over a million writes now I do think the amount of times the machine is going to used and the fact we only need to save the position after the job is done the eeprom won't burn out.


24AA1025 Eeprom.pdf

Now on further research it's the 47L04


47L04_47C04_47L16_47C16_DS20005371D.pdf
Edited 2026-06-01 16:39 by Bryan1

VAR LOAD doesn't count, that can be ignored.
VAR SAVE is one erase/write cycle per grinder operation.
At 10 operations per day that would work out at a lifetime of about 27 years before you would need to replace a flash chip or a Pico. (based on 100,000 writes, which may be conservative)

Data retention on either is probably around 25-50 years so, basically, VAR SAVE should last at least half the lifetime of the Pico.

Or you could note down the co-ordinates on a bit of paper. :)

That is the reason why we need printer support im MMBasic. No manual notes of variable content anymore !!

We've got COM ports, all you need is a serial printer. :)

Of course, with the extra IO on the RP2350B and the PORT command you can now have Centronics!

Gerald,

You can always get the variable values through the COM port to your development PC and print them.

Storage in the pico (flash) has the same reliability as SD cards (10k-100k). That is the A:/ drive, and the VAR SAVE area. You should evaluate how often you need to store data in non volatile memory before you can make a decision.

When it is once per few minutes, flash inside the PICO will be fine for years.

When it is often (once per second, or even several times per second) external storage is needed. But you have to evaluate how much pico CPU time you can spare to do the store. Most external devices will require 1 MMBasic operation to store one variable (with several parameters). That is I2C or SPI. So when you want to save an array or a structure, that is typically a loop of MMBasic commands. And that slows down. You do not want that slow down in a fast control loop.

I would personally look for the simplest implementation (the VAR SAVE). It is the fastest, and when you can limit the number of saves, you can use it a loooong time. You can always keep a spare pico if this one starts failing. For that money it is the cheapest solution.

Volhout

Hi, I came here from the year 2026 where we don't use paper anymore; we automatically send backups of everything to a device that we keep in our pockets (Bluetooth).

G'day Bryan,
No worries there, this is your project after all. To keep it moving forward Claude is probably a good move, as I stated, I have a million projects and work gets in the way of all of them, if you wait for me it'll be a long road indeed.

Maybe see how you go with Claude and I will try to help where needed, and I will continue to work on my version, we may be able to blend them together at the end.

On that subject, I have been working away in the background on the original code when time allows, this is to add an axis setup page and an axis homing page. This means you home the machine on power up and then it doesn't matter if its moved since the last job, so no need to store positions. Only the Z-axis is causing me problems, a homing switch would not be accurate enough.

Axis Config Page:


The other problem is I'm trying to make the code work for any CNC so it all takes a lot more thinking about, but I love a challenge.

Regards, Lyle.

Hi Lyle,

Touchscreens (also the small ones) tend to get very smudged by oily hands on CNC's. I don't know why...
And they become hardly readable. Maybe you should avoid small fonts, and dark colors (single pixel dark green/red on black). The big buttons are fine. The E-STOP should be a hardware button (touch is not reliable enough to save lives/hands/fingers).

Those are my 5 cents.

Volhout

Agreed. There may not be a display (or even a Pico) when an ESIOP is needed. Also, you may not be adjacent to the control panel, you (or a potential rescuer) may be closer to the door attempting to avoid shrapnel. That's what ESTOP loops are for. I even put a latching button right by the door in my shed to kill all the supplies.

G'day,
Motorcycle visor "Tear-offs" are a great way to stop the magical ingredients in cutting fluid destroying the touch screen, also have some capacitive versions to try  

These 4" displays are a nice compromise, larger would be better but the config screen shown is rarely used and the main screens have the larger buttons.

The "E-Stop" is just an indicator for the wired E-Stop system, hence the reason it is shown disabled, the loop is intact.

The "RESET" does as its name suggests once the system is in a suitable state.

Regards, Lyle.

Ah. :)
Does clingfilm work on the displays? I've used it on those tools that have "non-slip grips" that go all sticky and yucky.