Question

[WildPoYo]

Still working on this project?

[jschoch]

it works so I'm not doing a whole lot but happy to help you out or consider features. what do you need?

[WildPoYo]

I'll go through the code for now, will take some time since there's quite some code to go through :) but probably I'll have some questions :) also will write my own web layer with Javascript only. I have an embedded Linux touch panel which I plan on using for operating the whole lathe, since entire electrical cabinet needs some work.

[jschoch]

there is quite a bit of cruft so feel free to ask questions. A lot of unused code from some abandoned ideas that I did not bother to clean out (not much engagement from users). The json should be fairly straight forward but it was not exactly planned out. There is an "status" json doc and a "state" doc. the web UI sends commands, the controller evaluates them and updates state and propagates that state back to the web UI.

i'm not using any buttons or the display code since the webUI was good and responsive and easier to work with. this is a big chunk of the cruft, I was assuming it may be useful to someone else but I never really liked the code.

also the config is a bit sprawling and there are likely lots of unused configuration variables so sorry about that.

There is a closed issue here that has a bit of documentation about the setup that may also help you.

All that said it works great and I've had no problems using it on a phone or tablet.

[WildPoYo]

Yes, I started reading through the issue where you placed a lot of valuable info :) I was wondering if you are using any logic level shifter for converting your signals to 5v?

[jschoch]

nope, 3.3v seems to work fine form most stepper drivers i've used. the esp32 grbl fork uses i2s and shift registers to get 5v along with additional axis (6) with less pins. It seems to work well but would be a bit of work to move.

[WildPoYo]

I've seen you mention in several places, you would use esp32 grbl for els? I have a slightly large older lathe, stepper I plan to use is 12nm nema42. Min voltage for the controller is 5v so I ordered some level shifters since I don't have any optocouplers around.

[jschoch]

not quire sure what you are asking, esp32 grbl does not support spindle sync. I'd use it if it did though but I don't' believe bart has any plans to add that as a feature.

[WildPoYo]

Yea that was what I meant but I did not know there is no spindle sync. Actually i just checked and it is on the roadmap but marked as --Not on near term roadmap now-- so probably won't happen any soon. Once I have the parts here I'll build some testing environment and give your version a try and piece by piece trim the code. If you don't want to have this as an open issue, you can close it or we can keep it open and I'll pop something here once in a while.

[jschoch]

we can keep it open. i may add NVRAM storage of configuration this week.

[jschoch]

I've added a bunch of stuff and done some cleanup. Wondering if you are up for discussing the UI?

[WildPoYo]

Just checked your latest commit, tnx for the cleaning :) How can I help you?

[jschoch]

Just looking for some feedback on the UI.

Here's the reworked version

**

**

the updated controller is the nvram2 branch, and in the frontend "refactor" branch

The pitch settings are in the "jog settings" button. The "enable rapid button toggles" are a bit unsightly but I think it would be good to keep a rapid direction locked out so you can only rapid "back" to where you started. They are big because I use a tablet touchscreen to run the lathe (phone works well also).

I worked a bit on rapids and I'm just not sure how to deal with acceleration. Right now it is just slaved to the spindle with no acceleration. If you tell it to "rapid" with the spindle off and then turn the spindle on the motor will ramp with the spindle acceleration. If the spindle is running and you "rapid" too fast the motor will stall. Since all the motion code is slaved to the spindle i'm not really sure how to "make up" for a spindle that is already running. A closed loop stepper deals with this much better than an open loop stepper since it will make a "best effort". I put in accelstepper but it has problems running in an RTOS task. There is a very promising fastaccelstepper lib but it uses the MCPWM peripheral and command queues and I'm not sure I can get the spindle sync code working with it. So long story short rapids are based on a rapid pitch slaved to the spindle and there is a chance you set it too high for the current spindle RPM and you motor stalls and you loose position.

I also have a "mode" lockout, when it starts it sets the mode to "startup" and you have to set it to "slave jog mode" in the UI to unlock it. This is somewhat of a safety feature but since you have to click on the jog tab it may not be needed. wondering if this is something you'd want. I was also planning on locking out the debug functions unless you set it to "debug mode".

This is the new NV ram screen (with the old status display). Wondering what you'd want to persist in the EEPROM? I plan to put in the UI update rate and a few other things. I'm not yet planning on pin remapping via this but that may be possible.

For threading i hacked in an "offset" that moved Z just a small amount but I think I should just make the spindle "start" point settable to a relative distance or angle. This would make threading without a compound easier and it would allow for multi start threads.

Finally i'm working on a "bounce" mode that will feed a direction and automatically bounce back to the starting position via a rapid. This is 90% of your lathe cutting and it would be handy. Wondering if I implement it in the UI or add it to the controller and manage it via the state machine.

[WildPoYo]

Assuming you are using your tablet in landscape mode, most of the features that are needed could be placed in one main(home screen) and everything else can be kept away if they are not meant for operation itself(threading/feeding).

I still don't have my hardware yet, so I do not have the web server running to get the response, but from what i see, react is too heavy for such simple control unit. Combination of SVG's(optional) and JS/HTML/CSS should be more than enough and more lightweight. WS does not need any framework to run, most of the time I use plain WS with Javascript and its sufficient. Nevertheless, I'll give you proper feedback once I have my test setup ready.

My initial plan was to control my lathe entirely via web application. As I said earlier I have an older lathe that also has a dedicated oil pump, light, coolant pump. So ideally I'd strip the web layer completely or move it to a different interface.

But I'd still like to help you with this version and the web layer also.

Regarding to motion being slaved to the spindle, instead of slaving everything to the spindle, creating a state machine that tasks spindle(encoder) and motion(stepper) in separate cores and purpose of core0 in this case can be only constantly tracking the position and if position is not changing(spindle off) taking an acceleration or rpm base from configuration to the rapids. To make sure that there is no jumping issue if you turn on the spindle while a rapid is happening, you can monitor the rpm and adjust only when it is stabilized for a certain duration. ofc considering all those happening only in feed mode. if you are in threading mode, your base is always encoder output(not slaved but dependant)