This tool can extract firmwares from a firmware package
We can decompile the Android app, but cannot update it due to lacking the signing keys. Perhaps we can uninstall the existing version from the touchscreen and install our own
EDIT: Plugged touchscreen into PC hoping that it might appear as a generic ADB device. Nope. Doesn’t even power on. Wtf are we supposed to do with this. Either way, something needs to happen soon, cause my logs are filled with SSL exceptions being unable to accept a cert. I would be very surprised if SM issued an OS update for the TS. It is likely the next update will have to be manually applied via USB, these exceptions occur just after ‘DEBUG,SC,Start checking new version…’. Looks like touchscreen auto-update is broken.
It was my suspicion as well that they used the “phone” portion as unix shell and the os in the cortex chip in the controller. What a convoluted set up… Such an complex way to send step commands… Even if I can get the cortex chip reflashed and can get error reports, the use of a splitter effectively kills that getting back to the controller. Way too complicated. There are two paths I see ahead of me, gut the system, toss the touch screen and install a bigtreetech skr v1.4 and run a bigtreetech interface touchscreen. Or redesign my replacement board as a closed loop system to ensure that all steps sent to the rail through the can lines are followed ensuring no skip steps and figure out how to place a small interface to each closed loop board for calibrations, errors and setup. Nothing is simple.
Not completely true - the controller talks to all linear modules as CAN is a shared bus. If your new chip were to communicate with CAN it would have no problem talking with the controller, even through the splitter.
The touchscreen essentially does nothing, I occasionally operate the machine with it disconnected. It adds wifi and thumb drive support and a fancy HMI and otherwise is not needed. The machine will boot and operate via USB just fine.
I’m not 100% what you’re currently designing but I think it’ll work with this current system.
Step commands are not sent over CAN, but rather over dedicated signal wires. There are three, the same standard three on all inexpensive stepper controller chips: step, direction, enable. I’ve been presuming they did this purely out of expediency, given a lack of ability to use CAN effectively. If you’re going to send motion commands over CAN you need to get simultaneity over a network, and that requires something non-trivial. From what I’ve seen of the Snapmaker modifications to Marlin, they did not have the skill in-house to be able to do this, so they went with separate signal wires.
As for “all steps sent to the rail … are followed”, this isn’t possible with the current hardware. There’s no sensor to detect motion, not even for relative motion much less for absolute motion. There’s a whole class of DRO sensors out there now that use the same sensor system as the inexpensive digital calipers. It would definitely be a lovely thing to have something like a linear module with integrated DRO, but it would significantly increased the cost of the module.
Far less expensive would be to have used a chip like the AS5047, which uses a Hall effect sensor for measuring rotation on a shaft. For an example of what this chip can do in practice see the smart stepper that’s been built with it. The angular resolution of this chip is adequate for detecting individual missed steps. It’s not really a great foundation for linear measurement because you’d need an accurate map of lead screw and lead nut variation, as well as a repeatable end stop. With a bit of care in keeping track of possible error bound, though, it could provide an accurate measurement of absolute angle.
With a splitter the signals are duplicated and it can’t distinguish between the rails. An example of this is with the y axis off you can have both z axis stepper at different heights. Whichever get to him first is how they are both will act. I believe this is a terrible idea.
It can distinguish because the individual rails have unique addresses, and they are referred to by address over comms. If you watch the bootup process over USB you can get all the addresses, it reads them out as they identify themselves.
You are correct that whichever Z endstop triggers first is the one that is acted upon. But the controller knows which of the 2 endstops triggered because of the “from” address in the message.
Edit:
In a little more detail in the firmware:
// Each endstop has its own callback.
case LINEAR_AXIS_Z1:
cb = LinearCallbackEndstopZ1;
break;
case LINEAR_AXIS_Z2:
cb = LinearCallbackEndstopZ2;
break;
Fun fact, looks like up to 7 linear modules are supported, including dual X axes.
Edit again: It’s worth pointing out the CAN “address” concept is not technically accurate, the messages are distinguished by their data, which is not a perfect analogy to a typical TCP packet structure with an explicit address. However, at init Snapmaker passes around MACs as data for the purpose of initializing, and then switches over to “Message IDs”, where each ID is mapped to a call back function, effectively behaving as a “from address”, in the sense that “Message ID 5” corresponds to the Z1 end stop, for example (5 was made up, I’m not sure the exact number).
Yes. I am very well aware that snapmaker does not send the steps over can. A new board design would. Ideally an eithernet based controler would be faster, but it’s way too bulky. That’s why I was interested in seeing about reflashing the cortex chips to see if I could send steps over the can communication.
You can’t do better with the current hardware. There’s no absolute position sensor. There’s no relative position sensor to detect steps that would be missed on one side but not on the other. You’d need to have the limit switches calibrated so that they trigger exactly at the same distance from the end of the module. The mechanical switches they use are incapable of holding such a calibration even if there were an adjustment mechanism for it.
The best that’s possible is to get the linear module pair in correct position upon assembly and then periodically check that they’ve stayed in the correct position.
@eh9 - I’m not sure you were around in the early conversations - he’s designing new hardware. Closed loop control is on the table.
@geared - I know next to nothing about designing motion control systems. Moving to CAN based motion is doable, and while challenging I think it’s doable.
Here’s how I would approach it, without knowing too much right now. I’ll throw this out as a starting place.
Individual linear modules should have closed loop control and they know their position in space.
When that’s the case the Bresenham step function can be deprecated, as high speed stepping is no longer required.
Without the requirement of high speed stepping, lower frequency CAN messages can be sent (maybe 100Hz or slower even.
The contents of those messages would be a broadcast of the current destination position as well as a per axis feed rate.
Each axis would individually parse their component from the broadcast and would proceed at the specified feed rate towards the destination.
If adding closed loop control is impractical I think given the maximum data packet size of 94 bytes, high frequency steps could be sent over CAN at perhaps 1kHz, which would be adequate. Each individual packet couldn’t contain a single step, it would have to be optimized to some degree, perhaps number of steps to take for each axis combined into a single packet. That would be a drop in replacement for the existing Bresenham step function, as that’s what it currently does. One or more steps per axis, per ISR invocation of the Bresenham step function.
I agree that’s why I think a standalone closed-loop system would be preferable than just replacing the stepper motor driver IC with dumbed down functionality. Something based off of a Stm32 or a variant there of.
But even with this implemented with the current setup I can’t use m122 debugging mode. It’s annoying, that’s valuable data.
What do you want M122 to do? I’ll modify the firmware and send you a custom version to upload if you want. Obviously the L6470 or Trinamic driver isn’t being used so it doesn’t have that information, but if there’s something else you want printed out it’s easy to do.
If 6470 or Trinamic drivers were being used it would output the following:
You are way better at coding than me… I would need driver register values for sensorless homing. I was considering using the TMC5161. I got six different angles I’m looking at including closed loop and figuring out which the best way to go. Nice to bounce some ideas off you. As soon as I get some more of the components I need to do some more testing, I’ll definitely hit you up. I already got a bigtreetech skr v1.4 turbo to do my experiments with.
Does M1005, M1006, and M1007 contain anything useful for you? I believe it’s M1007 that contains the current step count, which I think is basically what you’re after. After a home you could M1007, get the step count, and reference off that using the 400 steps/mm configured in M92 steps-per-unit (which is read with M503).
For Can based motion, longer moves for CNC and laser would be “better” as you could tell the modules in advance, as Brent said, and keep using a dedicated line for movment triggering. Go to X,Y,Z… NOW, got to X,Y,Z … NOW. like they do in plane formation flight. as the feedrate woudl also be sent (as in brents solution) the movment would be in sync.
After further thinking - sounds like you’re trying to do this open loop, sensorless. I think both things I suggested earlier can be done open and also closed loop, it’s not related to the frequency of the messages.
As long as the mcus in the module can keep track after homing that will still work to send updates at a regular rate of 100Hz or so.
Some sophistication may be required in the form of each module needing a basic motion planner to prevent new instructions from immediately being executed - the existing motion should be completed before executing new motion.
Stealthchop and spread spectrum are just an on off thing controlled from the local mcu right? It wouldn’t need to be controlled from the main controller right? In fact, isn’t the default method of operation of those drivers to dynamically enable and disable as torque requirements vary throughout operation?
There’s two ways, use UART configuration through Marlin or solder jumpers on the driver itself (if that option is made available) the only side effect is loss of torque which can cause skipped steps.