An Electronic Lead Screw controller using a Teensy 4.1

Well, foo. My RPI4 "server" is having issues. Think the hard mounting I use is difficult on the connectors. I bundled up the cables to make it neater, and it seems to be affecting the quality of the connections. Like not booting. Darn. Plugged and unplugged (while off) and got a little further, but never into the OS. I am booting from SSD, there's no SD card.

Well that idea will have to wait... Making things more difficult, I don't have enough power supplies for all 3 RPI4's. Had to turn off one of the RPI4s to steal its supply. Guess I need to get another supply to fully diagnose this. Worked fine when not bolted in place... Minor setback.
 
WobblyHand said:
But, on the road towards progress, I updated the rotary encoder count to 64 bits, so I can minimize any rollover occurrences.
Click to expand...

So, are rollovers really a problem?

I've got a time-stamping counter running on a 32 bit counter in a pic here. Basically it grabs the counter value on an event, and subtracts the previous value from the previous event. The difference is reported. With integer math, the difference is always correct, even over a rollover boundary of the 32 bit counter.

I was surprised this was the case, and had to verify with another individual that the math actually worked out that way. The only issue that could be a problem is if the events happened so far apart the counter rolled over twice between events. In my case that was impossible.

Depending on what you are doing with the math, is it possible rollovers aren't an issue?


Sent from my moto z4 using Tapatalk
 
dkemppai said:
So, are rollovers really a problem?

I've got a time-stamping counter running on a 32 bit counter in a pic here. Basically it grabs the counter value on an event, and subtracts the previous value from the previous event. The difference is reported. With integer math, the difference is always correct, even over a rollover boundary of the 32 bit counter.

I was surprised this was the case, and had to verify with another individual that the math actually worked out that way. The only issue that could be a problem is if the events happened so far apart the counter rolled over twice between events. In my case that was impossible.

Depending on what you are doing with the math, is it possible rollovers aren't an issue?


Sent from my moto z4 using Tapatalk
Click to expand...
Using signed integers, it is manageable. However, sometimes these things are set up or used with unsigned integers. That really is bad with a rollover. Instead of the expected -1, you get the max value for that integer. When I was converting over to an int64_t, I messed up, and witnessed such a rollover. Fortunately my code flagged the delta >> 1 as it as an error and halted the stepper. Some encoder libraries are uint32_t, so be careful. For instance, Clough42's encoder is uint32, or at least it was on May 2022, when I cloned his code. Encoder.h shows "Uint32".

For a processor such as a Teensy4.1, there's practically zero penalty for me making the change to int64_t on the encoder library I am using. For other controllers it could be a royal pain. With 64 bits, it is a non-issue in a practical sense.
 
My thoughts on roller over the same as [mention]dkemppai [/mention] - timers are unsigned and they roll over without an issue. Counts should do the same.

For debounce, why not just use a global debounce value that gets set to the timer when an event first comes in. Just check if the global debounce time is past a threshold before recognizing any new event. ?
 
@jwmelvin Whenever using unsigned integers you have to be careful with them if they should over or under flow. If you work out the details and it doesn't matter, then great. But woe onto the programmer that doesn't think of this in advance, especially if there's math or conditionals in their code. Because stuff fails in strange ways. I have warning messages from the compiler that I still have to go through about mixing signed and unsigned variables. Have to figure out what's wrong and fix it. Because that's the kind of stuff that ends up biting you in the posterior! Or not you, but someone else using your code.

Have some ideas on debouncing that parallel your approach. The assumption is that only one key is pressed at a time. For the most part that's true, although if one has fat fingers or poorer motor control, multiple key selection may occur. If I was to make this bullet proof, I'd have to consider the case of multiple keys being pressed and what to do. Some action or blocking can take place in the touch sensing, but I guess that the state machine has to ensure that the sensed key presses are safe and compatible.
 
Made a long overdue git repo for development of my code. With all this code now, was afraid of making significant changes and not being able to get back to a working state. Sometimes your ideas don't work out and you want to revert to a known good state.

Like last night when I was floundering about with text formatting. Thought I understood how to use a lot of variables in sprintf to concatenate strings for later display. Nope, got something very wrong. So wrong it looked like a memory leak with random characters being inserted in the front of the string. So I reverted. I'll figure it out later on a simpler sketch. My C and C++ skills are not that good, so anything "cute" takes quite a few tries.
 
Got my RPI4 server operational. I had disconnected the failed RAID, but forgot to "remove" it from fstab. The system wouldn't boot, It would always go into emergency mode, with no way of correcting things. That was a pain. Had to connect the disk to another computer and look at all the main files, ie. cmdline.txt and config.txt. Everything checked out, there was no corruption. The PARTUUID's matched. Then looked in fstab and saw the RAID array was defined but there was no HW connected. Commented that line out and saved the file. Reconnected the disk to the RPI4 and successfully rebooted! Think I will use this guy as the main local repo. That is - after I get another power brick for it. 2 supplies and 3 PI's just doesn't work.
 
git server and repo are set up. Took a couple of tries, but got it work. Learned the hard way one needed to use fully qualified paths. Was able to make an empty repo on the server, and then uploaded from the lathe RPI4 git repo, and then made the RPI4 gitserver become the origin. Then I was able to use my laptop to clone the repo and have a local updated copy. Only have one more device to get in there - my display development platform, also powered by an RPI4. That will have to wait for another power supply, which I ordered today. Been quite the circus, but I hope this will keep these platforms under some level of configuration management. Got to read up more on git, so I don't mess up the hard work I put into this.
 
One thing I've been thinking about for my ELS project, which would be sort of a ripoff from the Hardinge lathes, would be a potentiometer controlled feed speed. Having a pot (maybe even a 10 turn) as an analog input to manually dial feed rates in could be handy. With an ELS only an analog input would be needed with a few lines of code to read it.

I had planned on adding this as a feature. It should be quite easy to implement a display of in/rev or mm/rev, and take the input value from an analog input rather than the touch screen. Not sure if you've considered something like this...
 
I like the knob idea but I’d make it an encoder so you can use the input for a variety of things.
 
You must log in or register to reply here.
Back
Top