Progress has been made. I have five JST stepper cables to connect the four stepper motors, one is in the Z axis already.
I’ve downloaded the V1 Marlin firmware as the first to test the SKR board. I’ve got that compiled with platform.io with the BigTreeTech TMC2008 V3.0 drivers and commented out the E1 extruder driver so it should only be working on X, Y, Z and E0 stepper drivers.
When the board starts, I get a nice V1 Engineering logon and the standardish Marlin firmware screen. I also get TMC Connection Error. Rats.
However when I go to the motion control screen, I can move the X, Y and Z stepper motors. I can go backwards and forwards. Woohoo. Worked first time.
All of the motors and circuitry is on the dining table whilst I work out how to fix the TMC Connection Error. I suspect a compilation issue, wrong driver or something, so will add the DEBUG flags and work out what went wrong.
Progress though of sorts. Having three stepper motors whirling around on command is pretty neat. Now I wonder how I can test the E0 stepper motor?
Enabling TMC_DEBUG and then sending M122 is pretty helpful. If you have the E0 driver set to TMC and don’t have the driver installed, that will do it. For now, just change the driver type of E0 to drv8825, which doesn’t communicate with Marlin.
Thanks. I’ve now just attached the Z axis to the motors so all five TMC2008 V3 drivers have a motor connected. I’ve also updated the code to add in TMC_DEBUG and issued the M122 command.
Each of the x, y and z axis seem to work OK from the LCD panel.
There seems to be a lot of errors with this, so I’ll try to work through this and work out what the problem but any advice welcomed.
Thanks
Rob
M122
SENDING:M122
Enabled false false false
Set current 800 800 800
RMS current 1436 1436 1436
MAX current 2025 2025 2025
Run current 25/31 25/31 25/31
Hold current 12/31 12/31 12/31
CS actual 0/31 0/31 0/31
PWM scale 0 0 0
vsense 0=.325 0=.325 0=.325
stealthChop false false false
msteps 256 256 256
tstep 0 0 0
PWM thresh.
[mm/s]
OT prewarn false false false
triggered
OTP false false false
off time 0 0 0
blank time 16 16 16
hysteresis
-end -3 -3 -3
-start 1 1 1
Stallguard thrs
DRVSTATUS X Y Z
sg_result
stst * * *
olb
ola
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
X 0x00:00:00:00 Bad response!
Y 0x00:00:00:00 Bad response!
Z 0x00:00:00:00 Bad response!
Testing X connection… Error: All LOW
Testing Y connection… Error: All LOW
Testing Z connection… Error: All LOW
X Y Z
Enabled false false false
Set current 800 800 800
RMS current 1436 1436 1436
MAX current 2025 2025 2025
Run current 25/31 25/31 25/31
Hold current 12/31 12/31 12/31
CS actual 0/31 0/31 0/31
PWM scale 0 0 0
vsense 0=.325 0=.325 0=.325
stealthChop false false false
msteps 256 256 256
tstep 0 0 0
PWM thresh.
[mm/s]
OT prewarn false false false
triggered
OTP false false false
off time 0 0 0
blank time 16 16 16
hysteresis
-end -3 -3 -3
-start 1 1 1
Stallguard thrs
DRVSTATUS X Y Z
sg_result
stst * * *
olb
ola
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
X 0x00:00:00:00 Bad response!
Y 0x00:00:00:00 Bad response!
Z 0x00:00:00:00 Bad response!
Testing X connection… Error: All LOW
Testing Y connection… Error: All LOW
Testing Z connection… Error: All LOW
The TMC2208 V3 come in two flavours, step/dir and UART. You need to specify these when purchased OR you can solder two very small pads together on the underside of the driver board to move from step/dir to UART.
I haven’t got my head around this and whether I should do this or not, but suspect the fact I have the step/dir version BUT am trying to interface in UART mode (according to the pins on the SKR board) might be why I’m getting TMC Connection Error and the driver registers are getting bad responses.
Does this make sense?
If so, the easiest solution will be to buy the UART versions.
My hypothesis was that the TMC2208 were actually operating in step/dir mode rather than UART mode. I recompiled the Marlin code and changed the driver to TMC2208_STANDALONE, recompiled and uploaded. I no longer get the TMC Connection Error and the X,Y and Z axis seem to work well.
Now the question I have is should I move to UART or stay with what I have. I have TMC2208 UART motors on order but easy to send them back.
Yeah, if you have standalone drivers, they will act like drv8825s. They will work fine, but you need to adjust the current with the little screw potentiometers on the boards. If you can talk to them over uart, they will let you set the current through the software, and do stuff like change modes and stuff.
I have soldered those tiny jumpers on some tmc 2130s. I am pretty good at soldering, and I’ve done some easy surface mount stuff successfully and that was pretty hard (but I did manage to do it right.
It also looks like it is only expecting XYZ to be smart drivers, not 5 of them. I’m not sure what is going on, but I don’t think X2 and Y2 is configured right if you expected them to be uart tmc 2208s.
I now have a set of five BigTreeTech TMC2208 V3.0 UART stepper drivers. They look identical to the BigTreeTech TMC2208 V3.0 step/dir ones. I assumed the little solder pads would be soldered over on the UART version, but AFAICS they are no physical differences between the two version to my untutored eye.
I’ll recompile the source code back to the UART versions and reload the firmware up to see if they will talk via UART.
I have NOT wired the X2 and Y2 motors in series yet. However I have compiled them into the firmware as E0 and E1
as that’s what the SKR V1.3 board has as outputs. I haven’t really looked at the wiring for the X1 and Y1 motors to be honest, so might have got those two bits completely wrong.
I’m taking this slowly as I don’t want to damage anything and the day job that pays for all of this is all consuming as I have a big go-live on Sunday that’s taken a year to build.
The logical sequence is:
Get platform.io working on Mac and demonstrate I can compile and download - DONE
Get any version of Marlin V2.x.x compiled, downloaded and working. It doesn’t need to do anything just allow me to turn motors. Works with non-UART stepper motors and got rid of the TMC Connection error - DONE
Update the software to work with UART, recompile and get it working with no connection errors, check what M112 displays - TBD
Build an external plug board that wires the stepper motors into series, simple mode for CNC - TBD
Get the simple series working - TBD
Build an external board for end stops - TBD
Update the firmware to handle dual end stops - TBD
I’m taking it very steady and checking as I go. Each step builds on the next step so when it goes wrong I know what’s changed and can easily roll back.
I remember it differently. I think you define X2_DRIVER_TYPE and Y2_DRIVER_TYPE.
I like the logic of trying it with 3 drivers first. I would probably suggest at that point you aren’t far off from getting 5 drivers to work, so I would try that before making a series wiring harness. That is assuming dual endstops is your goal.
I have an older version of the firmware on my machine, and some people have liked me sharing it. I would suggest you use it just as a guide to see what configuration options I chose. It is for the low rider, skr 1.3, and 2209s:
To be honest I never even looked at the code for which driver beyond the X, Y and Z define It’s not surprise I for that wrong.
The UART steppers have turned up along with a load of wiring cable. I was planning to get the simple setup working without end stops and only then move to end stops.
I was hoping to get look at this tonight but suspect it will be next week now.
(yes I know this is wrong, but change one thing at a time).
and installed the new firmware. Got to say platform.io does a nice job of hiding the complexity of uploading and managing the SKR board. Very impressed. Now if I can get it all working like that with Emacs
M112 displays something sensible at last
>>> M122
SENT: M122
RECV: X Y Z
RECV: Enabled false false false
RECV: Set current 800 800 800
RECV: RMS current 795 795 795
RECV: MAX current 1121 1121 1121
RECV: Run current 25/31 25/31 25/31
RECV: Hold current 12/31 12/31 12/31
RECV: CS actual 12/31 12/31 12/31
RECV: PWM scale 14 14 14
RECV: vsense 1=.18 1=.18 1=.18
RECV: stealthChop true true true
RECV: msteps 16 16 16
RECV: tstep max max max
RECV: PWM thresh.
RECV: [mm/s]
RECV: OT prewarn false false false
RECV: triggered
RECV: OTP false false false
RECV: off time 3 3 3
RECV: blank time 24 24 24
RECV: hysteresis
RECV: -end -1 -1 -1
RECV: -start 1 1 1
RECV: Stallguard thrs
RECV: DRVSTATUS X Y Z
RECV: sg_result
RECV: stst
RECV: olb
RECV: ola
RECV: s2gb
RECV: s2ga
RECV: otpw
RECV: ot
RECV: 157C
RECV: 150C
RECV: 143C
RECV: 120C
RECV: s2vsa
RECV: s2vsb
RECV: Driver registers:
RECV: X 0xC0:0C:00:00
RECV: Y 0xC0:0C:00:00
RECV: Z 0xC0:0C:00:00
RECV: Testing X connection... OK
SENT: M105
RECV: Testing Y connection... OK
RECV: Testing Z connection... OK
RECV: ok
RECV: ok T:0
SENT: M105
RECV: ok T:0
SENT: M105
RECV: ok T:0
Motion control from the LCD works well for X, Y and Z. I have no expectations of it working for the E0 and E1 controllers yet.
Next step is to wire up a simple series controller to get X ands X1 etc working. I have Veroboard, soldering iron and solder.
To run dual motors on an axis, you should be able to enable X_DUAL_STEPPER_DRIVERS in configuration_adv.h. If I were you, I would try that before making the series wires.
Just compiled with X_DUAL_STEPPER_DRIVERS. Both X motors work and both Y motors now work. I changed the direction so they rotate in the same direction and can see that the secondary X and secondary Y motor are working at half the speed (or twice the steps) as the primary motor. However they are working, I think I’ll keep investigating this as ultimately I want to go this way with end stops. The motors are on the dining room table so they’re unlikely to cause any issues
Will look at the steps configuration as first guess.
Since I now seem to have five stepper motors working correctly, I may as well go for broken and get the end stops working. What can possibly go wrong…?
Yes the motors should run and will run opposite to each other. I wanted to measure how far out they were out as they were rotating in different directions AND at different speeds. My brain couldn’t handle the counter rotation so I flipped
#define INVERT_X2_VS_X_DIR true
to
#define INVERT_X2_VS_X_DIR false
Now I could see how far out they were.
I knew what I as doing on this one (might be a first all day).
The motors are fine and I’ll flip the direction later on.
At the moment i am experimenting with the dual end stops. The SKR V.13 board has six (!) slots for end stops. I have five end stops and just turned off the board, plugged an end stop in (three wires?) and ithe board refuses to start up. If I close the end stop, the board starts up. These end stops are commercial so it’s not my soldering and JTAG wiring this time. Kinda odd.
Need to investigate this further. Suspect that the Marlin firmware might do something with the end stops, but thats just my guess.
Agreed, though no damage appears to have been done.
I need to look at the wiring on the end stop. It’s a three wire, NC and NO and see what Ryan used and then work out how that transfers to the SKR V1.3.
I would have thought that min and max end stops were a good (great?) idea for safety and for calibration. Given how well the MPCNC is designed, is there any reason why they aren’t used? They’re pennies to buy, though many boards don’t seem to have four slots for end stop which might be the reason. I like the idea of autohoming back to the min end stops, auto max homing to the end and then you have a good idea of how regular the CNC bed is. If you combine that with a Z probe similar to a BLTouch, then you can build a very good map/mesh off the bed and do specific offsets.
DO NOT USE THE + (positive) Terminal. S & – (signal and Negative) Only
Xmin=X1 limit switch
Xmax=X2 limit switch
Ymin=Y1 limit Switch
Ymax=Y2 Limit switch
Zmin=Touch probe. Signal pin to plate, negative to tool.
For the safest configuration the endstops should be wired in the Normally Closed position (NC), to prevent wire disconnects from damaging the machine during the homing sequence.
I need to work out what this actually means and how it relates to my three wire switches, the SKR V1.3 board and the Marlin firmware. I suspect a glass (or two) of white wine may assist the thought processes.
I’ll revist this tomorrow or Monday. I have a big release tomorrow (Sunday) for work, so that may mean I have no time.
It’s not surprise I for that wrong.
