Kelly the Carver's Portable LR3 Build Thread - Ice Edition

I use BBEdit on my Mac.

For some reason when I downloaded the config from the FluidNC interface onto my Macbook it just opened up normally (into plain text mode) in TextEdit. I suspect that the file I downloaded from GitHub was the wrong file and was actually an HTML page because when I forced it t open into plain text mode it clearly gave me the HTML that would render exactly what the screen shot above showed. I’ll get BBEdit though - this isn’t the first time I’ve run into this in my life.

1 Like

Here is the proposed X section (the only change being the #C label and the name change to “motor1”:

  x:
    steps_per_mm: 50.000
    max_rate_mm_per_min: 9000.000
    acceleration_mm_per_sec2: 200.000
    max_travel_mm: 1220
    soft_limits: false
    homing:
      cycle: 3
      positive_direction: false
      mpos_mm: 0
      feed_mm_per_min: 300.000
      seek_mm_per_min: 1500.000
      settle_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100
    #X
    motor0:
      limit_neg_pin: gpio.25:high
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 4.000
      tmc_2209:
        uart_num: 1
        addr: 0
        cs_pin: NO_PIN
        r_sense_ohms: 0.110
        run_amps: 0.800
        hold_amps: 0.500
        microsteps: 8
        stallguard: 0
        stallguard_debug: false
        toff_disable: 0
        toff_stealthchop: 5
        toff_coolstep: 3
        run_mode: StealthChop
        homing_mode: StealthChop
        use_enable: false
        direction_pin: I2SO.1
        step_pin: I2SO.2
        disable_pin: I2SO.0

    #C
    motor1:
      limit_neg_pin: gpio.25:high
      limit_pos_pin: NO_PIN
      limit_all_pin: NO_PIN
      hard_limits: false
      pulloff_mm: 4.000
      tmc_2209:
        uart_num: 1
        addr: 0
        cs_pin: NO_PIN
        r_sense_ohms: 0.110
        run_amps: 0.800
        hold_amps: 0.500
        microsteps: 8
        stallguard: 0
        stallguard_debug: false
        toff_disable: 0
        toff_stealthchop: 5
        toff_coolstep: 3
        run_mode: StealthChop
        homing_mode: StealthChop
        use_enable: false
        direction_pin: I2SO.1
        step_pin: I2SO.2
        disable_pin: I2SO.0

Now that I’m learning and understanding more, and thinking more about something discussed earlier - the spacing between each X core, I COULD technically create a config file specific to each spacing requirement and using the individual pulloff_mm could set the position of the second core relative to the first? They are both going to pull off 4mm so if I wanted the second core to be 18mm from the first then I set the pulloff to 22mm?

1 Like

…ok. I figured, “I’m pretty sure it’s all fine.” and uploaded it.

No magic smoke and lights seem to be lighting the way they should but nothing is moving. There was an error thrown when trying to home the Z axis. X, Y and Z jogs did not move steppers.

$G
[MSG:WARN: Low memory: 10536 bytes]
[MSG:WARN: Low memory: 10000 bytes]
$J=G91 G21 F2400 X-1
ok
<Jog|MPos:-1.013,10.000,10.000|FS:240,0>
$J=G91 G21 F2400 X1
<Idle|MPos:-2.000,10.000,10.000|FS:0,0>
ok
<Jog|MPos:-1.987,10.000,10.000|FS:240,0>
<Idle|MPos:-1.000,10.000,10.000|FS:0,0>
$J=G91 G21 F2400 Y1
ok
<Jog|MPos:-1.000,10.038,10.000|FS:255,0|WCO:0.000,0.000,0.000>
$J=G91 G21 F2400 Y-1
<Idle|MPos:-1.000,11.000,10.000|FS:0,0>
ok
<Jog|MPos:-1.000,10.988,10.000|FS:240,0>
$J=G91 G21 F1200 Z1
ok
<Jog|MPos:-1.000,10.000,10.012|FS:240,0>
<Idle|MPos:-1.000,10.000,11.000|FS:0,0>
<Idle|MPos:-1.000,10.000,11.000|FS:0,0>
<Idle|MPos:-1.000,10.000,11.000|FS:0,0|WCO:0.000,0.000,0.000>
$HZ
ERROR:5
Homing cycle failure. Homing is not enabled via settings.

I will walk away quietly and wait for rescue. I’ve re-uploaded the original config and confirmed (by re-downloading) that this is the file in play now. It was moving before I made the changes to the endstop connectors but never did test the movement afterwards.

Let us see what $ss looks like in the webui terminal

These need to match the numbers from the commented out “C” section in that yaml

Also be careful not to add extra spaces on the end of the lines and stuff. Some spaces will cause it to fail.

Of course my new laptop doesn’t have VSCode on it yet.

Try this.
config.zip (1.5 KB)

If it does not work let us see $ss

Alive again. Thank you. I wonder two things.

  1. If my config I did indeed accidentally add an erroneous space or extra line.

  2. If merely by opening the file in the Mac’s text editor it does something to the formatting that messes it up. I did not make a change to the original config I downloaded from the Jackpot but did open it and it likely autosaved itself at some point because when I re-uploaded that file it was motionless.

I’m going to download BBEdit right now.

1 Like

Okay, I see you’ve added the second motor there, thank you. (I noticed the second core moved this time when testing so assumed you’d done some dirty work for me). I looked through your config in BBEdit. You didn’t have the reference to #C preceding the motor1 definitions as I had assumed was required. I guess that would be/would have been line 65?

Can I set the limit_neg__pin on motor1 to the same as the primary core? I’m assuming here that I could use that feedback and technically be able to use the pulloff as mentioned above (to set the core spacings). Alternatively I can set it to NO-PIN and manually space things like we’d previously discussed.

Now riddle me this. When the primary core moves, the secondary core appears to move exponentially. Meaning a 100mm jog to the left moves the primary core 100mm to the left but the secondary core only moves 70-72mm to the left. To the right, same thing.

No it needs it own pin…I actually already set it for you. I am not sure how that is going to work though so be ready to cut power.

Make sure the steps per mm in the yaml are the same for both and you have the same size pulley on both.

You’re far too efficient. Thank you. I’ll look up the pin and keep my fingers crossed that it’s not the one I snipped from the header rows. I’ll report back! I can always use this snipped board in the other single core LR3.

I haven’t made it back to the machine just yet but was thinking this through and had a couple of questions.

Is it something about the software that the two X cores can’t share the same signal/pin from the primary core’s limit switch?

If it needs it’s own switch then I’ll need to set a screw or something into the side of the primary core to trip the secondary core’s limit switch. I haven’t looked at the machine directly but am sure that’s an easy add. But this brings to bear the concern you had earlier about the secondary core’s homing being a moving target. Perhaps a delay can be written into the homing sequence for the second core/C driver?

ORRRRR…and this is me being absolutely naive about the real magic to these machines (the coding). I was thinking, if the limit circuit(s) is/are wired NC, why couldn’t I wire the secondary core’s pins in series with the primary core’s pins so that if either are tripped it’ll satisfy both at the same time? I DO have the limit switch and wiring in place for the secondary core - I’m not just being lazy here. Just thinking through with my dangerous lack of real understanding of how the software is written and what it needs.

I DO have an answer to the stepper setup. I used the Z stepper from the MPCNC and yes, it has a matching pulley to the other X core. Is it possible the NEMA 17 used on the Z for the MPCNC is different than the ones I am using for the LR3?

This sounds like you’re on the right track. Here’s something that happened to me: at the start of my use of a Jackpot, it was also my first use of a .YAML file. I did not know the parser for it is finicky about the number of spaces and about avoiding unneeded spaces after a line. I had a stray space or something, and it made one of my steppers hot, and made one side of the axis go at the right speed and distance and the other side not. I cannot remember if the other side went half speed and half distance or double speed and double distance. I posted my file, and someone here on the forum caught the space. I took it out, and the stepper works right.

Interesting…I wonder if we’re dealing with something similar here? That second X stepper remained a hot little number after the config Ryan set up for me. And it has that “not moving as fast as the primary” issue. How on earth do you even begin trying to find an erroneous “space” or extra line in that file??

For my editor for the config file, I use VSCode. I run it in “dark mode.” I hit “find” and enter a space… and it highlights all the spaces. You can just scroll through, looking at the end of each line. If you spot one, you can delete it.

1 Like

If you’d like me to take a look, just post the file here or send me via a direct message. (You may have to wrap it in a zip file to attach it.)

Thanks Doug. Don’t feel obligated, but it’s above from Ryan. The link to the zip file should stand out for you.

Nice to know there are still night owls out here, I think Ryan and Jeffe are getting old…

1 Like

I took a look. I wish I could say I found a stray space, but I did not. Sorry.

I thought the plan was just to clone the X? If that is the plan the config I sent you should mean both X steppers move at the exact same time. The first X has the endstop and does all the homing work, #2 is just along for the ride and does not need one. Doing it that way you can move them apart as far as you would like before powering on and they will stay that way.

1 Like