I just took a look at the config, steps and power are set the same. Hoping one of the pulleys is a different size? If it is we can just adjust the steps per mm of that one.
Hey! I resemble that remark!
Thanks guys. I hope it wasn’t too arduous digging through for an erroneous space. Pretty sure Ryan wouldn’t have but hey, it seemed too coincidental that the symptoms were so similar.
I’ll peek into that pulley and see if I can’t get a good tooth count but it’s for certain from the same package as the others - prior to that pack all I had around here were 6mm pulleys. Still, could be a goof up from the supplier (don’t worry, it was the Amazon, not V1 ; )
Yes, that was definitely the plan. Perhaps I misunderstood that by having a limit switch defined that the secondary core would also need to complete a homing sequence. I never actually tried homing X - partly because I noticed right away they were moving at different rates. I’ll do that today.
AFTER I re-clean off my work table. It’s now home to all the burly bits and all the other stuff that gathered on top of the MPCNC table which no longer exists.
On another note - my electrician sounds to be about ready to come finish wiring up my walk in freezer for me so we’re getting closer to freezing down this build and learning what shrinks where and where cracks start to surface.
Whoa. Who 3d printed the concrete wall in front of the Florida net tonight?! Our boys made great opportunities but nothing was getting by the masonry.
And I’ve confused my building materials yet again…
Okay, so I tried homing the X. Both cores moved very slowly to the X+ and then an alarm popped up. “Homing fail. Pull off travel failed to clear limit switch.” Is this because pin 39 is not connected? I’m guessing since the circuit across pin 39 is open right now that the homing sequence was trying to lift off the switch?
I also removed the cores and the X drives to count the pulley teeth. 16 each. Perplexing. I’d like to try swapping the X and C connections to see if that makes the primary core move slower than the secondary but that’ll be tomorrow. I only tidied enough to try the homing and then check the pulleys.
Yeah, my bad it should look like this,
direction_pin: I2SO.1
step_pin: I2SO.2
disable_pin: I2SO.0
motor1:
limit_neg_pin: NO_PIN #gpio.39:high
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
hard_limits: false
pulloff_mm: 4.000
tmc_2209:
uart_num: 1
addr: 3
cs_pin: NO_PIN
I wanted to list the pin, but not use it.
OK. Made that edit and nothing broke. Thank you.
X will not home nor does it generate an error. I can jog both steppers in either direction. I did not try moving it onto the limit switch and homing - should I try that?
Here is what the config for Motor1 looks like now.
motor1:
limit_neg_pin: NO_PIN #gpio.39:high
limit_pos_pin: NO_PIN
limit_all_pin: NO_PIN
And the config itself -
config.zip (1.5 KB)
I swapped X and C connectors to check the jog speeds and it appears that C on the board is the culprit. When swapped, the primary core is the one that then moves slower and the secondary core moves faster.
I think you are missing this in the motor1/C axis:
cs_pin: i2so.22
Under X/motor1, change cs_pin from NO_PIN to i2so.22.
For the Jackpot board with tmc2209, the uart number is always 1 and the address and cs_pin determine communication routing:
X: addr 0 cs none
Y: addr 1 cs none
Z: addr 2 cs none
A: addr 3 cs i2so.14 (Y2 for lr3, X2 for mpcnc)
B: addr 3 cs i2so.19 (Z2 for lr3, Y2 for mpcnc)
C: addr 3 cs i2so.22 (X2 for your setup)
If the setting is not right, uart will not work and this causes microstepping to be the default instead of your setting.
Made that edit and uploaded. No change. I downloaded from the machine to be sure the change was indeed uploaded.
config here:
config.zip (2.1 KB)
I feel bad now that this is turning out to be much more of a challenge than anticipated but I’m grateful for the help being offered (as always here). I hope when we see this bad boy running, carving twice the ice as a single core LR3 it’ll all be worth it.
Looks okay to me… not sure what it might be.
Are you powering down the Jackpot after uploading the new config file and then powering it up again?
If not, it won’t load the new config file.
I’m restarting it in the UI. I’ll try a fresh boot here in a bit.
Something strange afoot for sure. Fresh power up and nothing was different. But then I noticed some oddities I hadn’t before. Using the config with that one change Jamie suggested none of the axis would home. I reloaded the one rom Ryan (historically most recent) and all axis homing returned albeit with the error from before which was deemed to require the “NO_PIN” edit.
Both configs in the attached ZIP. There’s no chance this is still an issue of me opening the configs (in BBEdit) on a Mac is it? Could I trouble someone to make the “NO_PIN” change noted by Ryan and cs_pin change to i2so.22 as noted a couple posts above by Jamie and post the config for me to try?
One last note, just to be sure I swapped the TMCs between X and C but no change noted - the C core is still moving slower.
Configs.zip (5.5 KB)
I made this change:
I read that you can’t have a #comment on a config line. So I deleted #gpio.39:high.
limit_neg_pin: NO_PIN #gpio.39:high
Hopefull this will work now.
config.Jamie.zip (2.0 KB)
Awesome thanks everyone! I definitely missed that.
Success! Thanks so much for taking the time to look into that. Amazing how particular the config can be. We’re homing just fine now on the x axis (and Z…and presumably Y - I’m not on my table yet).
And just when you think you’re out of the woods we have one last “Version 2.0 Oddity”. It’s got me doubting my memories but as near as I can recall and according to how many times I said it above it must be the case. The secondary core is now moving FASTER than the primary.
I triple checked my brain and am certain certain certain that all this time the secondary core had been the slower of the two and again - based on how many times I said it above must believe that to be the case. Thinking that maybe yesterday when I swapped the TMCs I didn’t notice the fast one had swapped I swapped them back to original but yes - the secondary core is now moving faster than the primary core.
The primary core moved the expected 100mm, the secondary moved 145mm.
Awesome. I’m glad to see that part is working.
Maybe @MakerJim and @SupraGuy can help you figure out the remaining stepper problem. They helped me get my rotary figured out and working correctly.
I have one of those Hobby CNC controllers too! Still have the 4th axis parts in a bag!
That is just nuts.
At least it does make sense that previously it was moving 72 vs. 100 and now it is double at 145 vs 100. I think the reason is the microstepping = 8 was not taking effect without i2so.22 and microstepping at 16 by default. Now with lower microstepping it moves twice as fast.
But there is no reason it should be an odd ratio. Bizarre. I may just have to hook up my Jackpot to my Dual-X LR3 with your configuration to find out.
Time for some logs.
Power up, home X, do a test move to show that it is misbehaving.
Then tell us what you get with the following command from the terminal:
$SS
Loading one up now to see if it happens on my end as well. Guessing it will.