Hello @JKC20. and all of you guys,
is there a GitHub repo for the Snapmaker FW code? It would be great to have also the FW GitHub.
I have a feature request:
Is it possible to add on the info page, or a new maintenance page, of the touchscreen the total working hours of the machine? I think it will be very useful if we could have the n. of the hours the machine worked (printing, CNC, laserā¦) so that we can see if some maintenance is needed or not.
Also a reset button will be fine so that we could reset after maintenance or cleaning up orā¦
There isnāt an official one yet. but @ITmaze has created one including a commit per published firmware on this forum to make it easy to track changes:
originally posted here:
@Edwin also announced that a publication by Snapmaker would happen this month (November). I assume this would be on Github:
If you can create a GitHub issue for that suggestion, we can keep this kind of idea all in one place and when SM release their firmware source, we can update their issue tracker.
Edit: On a serious note, that looks like a good repo, good job Snapmaker.
I think the source code for the Android app is the final piece of the puzzle? And also the module firmware? Although I guess Snapmaker is not required to publish the source for them, unlike the main Marlin fork
Insofar as I can tell, this is the source for the firmware in the main controller. It does not include any of the source code for the firmware inside the work heads. For example, temperature regulation for the FDM hot end is in that controller. PID parameters can be changed over CAN, but control is local. Per docs/Hardware-Link.md, thereās an upgrade module command over CAN for firmware changes. Iāll note that naming this āupgrade moduleā rather than āreplace firmwareā is just so replete with enuthusiasm.
So, no, itās not the final piece. If theyāre to open source all the firmware, it needs to include all the module firmware as well.
I was just looking at this file as well. For all the promise that this is a CAN-based machine, itās only partially so.
The linear modules of stepper motor has control signals going over dedicated wires, but the limit switch signal goes over CAN. <sigh/> One of the promises of this design, as a CAN machine, is that you could get rid of non-CAN control wires.
The laser module uses one of the stepper signals for power control. So presumably power control is done with PWM over this wire, rather than controlled locally. (Should be easy enough to verify.)
The laser module has a whole second UART bus, reusing a pair of stepper wires. Thatās just insane. You can put two CAN devices on the same physical bus; why didnāt they?
Thereās Bluetooth in the camera inside the laser head?? Why a second channel?
The CNC module has nothing listed about reporting state back to the controller, not even, say, a motor stall condition.
I believe that uses the same PWM pin used for the laser PWM. It doesnāt, it uses CAN.
Correct
I think thatās a mistake. The bluetooth MAC for the camera is read via CAN, and I believe thatās reported via UART local in the toolhead mcu. Itās not read via CAN, itās serial.
I think CAN doesnāt have the bandwidth. It goes straight to the HMI and is why you canāt use camera calibration via USB.
Spindle speed is reported via CAN. However, the controller doesnāt check for stall conditions at the moment - itās something easily added though and Iād like to give a shot at implementing soon-ish.
The block diagram doesnāt have all the answers, and itās not all 100% correct, but itās a good start.
Iāll start by saying Iām just reading the documentation. I certainly wonāt claim that the documentation as published by this manufacturer is correct.
It may well be. That same section in Hardware-Link.md does say that it uses three analog pins. Presumably one is for filament feed. Another might be PWM power control. It does also say, however, that PID parameters can be set over CAN. Perhaps both are involved, gating with PID start/stop control a PWM signal that sets average-power-when-on; that seems like it would be rather an unnecessary overcomplication.
The documentation seems to say otherwise. The source code should provide an answer; I havenāt looked there.
CAN doesnāt have a single specified bandwidth; it depends on what physical layer youāre using. The high speed standards are for 1 Mbps or 5 Mbps. Low speed is up to 125 kbps, as fast as an ordinary high-speed UART. I donāt know which physical layer or electrical interfaces are in use in this machine, though. The popular and inexpensive MCP2551 is 1 Mbps; the current MCP2561FD goes up to 8 Mbps. If they didnāt put in at least a 1 Mbps bus, itās just shooting themselves in the foot. Itās barely more expensive than a low speed bus and youāre not in an automobile wiring harness picking up spark plug noise.
Is it? Are they reporting actual speed from a tachometer sensor or back-EMF sensor or the like, or are they just returning a stored value?
After further looking, there is a serial channel, mapping back to USART3 on pins PB10 and PB11. PB10 is also used as the extruder stepper direction pin, and PB11 is the extruder stepper enable pin. (The extruder STEP pin is also the same PB14 as the laser PWM).
Yes, the motor has an FG frequency generator pin, presumably it comes from there.
āSpindle speed is reported via CAN. However, the controller doesnāt check for stall conditions at the moment - itās something easily added though and Iād like to give a shot at implementing soon-ish.ā
@brent113: Can you please explain me what do you like to implement? Iām just wondering what will happens if working on CNC the bit get stuck on the material or for instance trying to make a hole the bit canāt drill the material (too hard orā¦). Are these the cases youād like to manage?
Prevent motor stall is more to protect the motor than the bits. A stalling motor can easily overheat and burn out the insulation on the fine wires inside, requiring replacement. It can sometimes, of course, save a cutting bit.
Canbus is currently configured to run on 500kBit/s, or atleast my analyser is happy with that rate.
Waterfall log so oldest at bottom newest at top.
0x15 Talk to CNCN module
0x614 reply byCNC module
0x614 0x00 0x00 0x00 is steadystate aka thats whats reported on CANbus
interval is 500ms
Spindle slows down
0x15 0x00 Turn off spindle
Stindle speed up and reaches speed
0x15 0x64 Turn spindelspeed to 100%
0x614
3
0x00
0x00
0x00
0x614
3
0x01
0x2C
0x00
0x614
3
0x10
0x68
0x00
0x614
3
0x27
0x74
0x00
0x15
1
0x00
0x614
3
0x2A
0x94
0x00
0x614
3
0x25
0xE4
0x00
0x15
1
0x64
Just tested if the controller panics if the CNC module doesnt respond, it crashes. The Screen stays responsive, when telling the controller to home via screen, its hangs up aswell. after 10s or so the linearmodules get unlocked and you can move them.
Powercycle fixes the crash state.