I’m not sure this is a good idea. I’d prefer that FluidNC comes up, so you get all the FluidTerm logs if the terminal is up, and you get the WebUI so a user without a terminal can at least interact with the system. You’ll get warnings in the WebUI about the state.
I poked around a bit and it seems like it would be messy- but I’m a hack not a proper software engineer.
I don’t think it is so much FluidTerm that forces the reboot, but rather plugging in the USB cable may have that effect depending on what the USB Host OS does on device connection with respect to the hardware handshaking lines on the CP2102.
Joking aside… assuming that all the information in there is accurate, it’s actually a pretty impressive set of information it put together from the code…
Whoa that is too freaking cool. It the stepping section of fluidnc it even gives the configurable setting and their bounds. I love that need to keep poking around to see what else is in there.
PS I am even more impressed with how complicated it actually is. I just knew it was above my pay grade. I am getting a better sense of how far above now.
It was completely rewritten starting in 2011… It’s just a complicated system… and there’s a ton of little details that are hard for people to grasp as to why it’s there.
Maybe the TMC stuff could just report a status of ready not ready and then it would refuse to start until VMOT was on. Then you couldn’t leave idle or something if tmc wasn’t ready.
I was suggesting just a first step. In software we tend to think in small steps and getting a “minimum viable product” out first, then see what patches or optimizations are the most important. “Premature Optimization is the root of all evil” is a common saying in SWE.
Up at the systems engineering level this is sort of a requirements definition failure.
It really should be that one of the first things the software does is to make sure the hardware is ready, then act accordingly.
If VMOT is off, you shouldn’t just merrily slog on through driver init failures or present a UI without an obvious indication that the system state is invalid for use.
Houston we have a problem. The new boards are here but the pendant is causing issues.
I can make the pendant work just fine, all that is functioning as it should. So I have to assume the wiring and firmware side are as they should be.
The jackpot does not like to boot right with the pendant plugged in. Matter of fact it draws nearly twice the current that way and does not seem to fully boot.
If I boot and then plug in the pendant it works fine, shows no significant current increase maybe just 0.01-0.02A extra if the meter is even that accurate.
The other issue is if I leave that plugged in the 5V 3.3v PS section on the jackpot starts to get real hot.
Vmot is not being used, nothing soldered to the pendant end.
The voltage on the lines seems fine, 5V is steady (probably need to put the scope on it.)
gpio12 and 15 have 3.2 and 3.1v on them (odd that it is not 3.3?? or is that becuase they are data)
So the pendant has Fluidnc, correct. I wonder if it seeing that is causing the boot problems. Is there a way to turn the comm to pendant on at the end of boot???
yeah boot caps are normal…and touchy that is why I moved one of our outputs.
I guess I can pull off the protection chip and straight wire it and see if that corrects the issue. To at least narrow this down. I will try that first thing in the morning.
Sorry man, when this is your bread and butter, i know this is tough! @jono035 any thoughts pal? hey seriously though, am i getting on your nerves pulling you into these disccussions?
