Anyone get theirs working yet?

[xobes]

I got mine all wired up and I'm starting down the road of trying to figure out why it's not working :-)

I.e. learning the G-codes to try and drive one motor at a time....

Anyone beat me to it?

OK, I got my C axis moving, and my Extruder as well. My Z axis always claims to short out, I've tried using the Extruder's wiring, same thing. X and B are ... ugh.

With respect to X and B, I'm struggling to understand now the axis:drive mapping: M584 Z4 C0 X1 B2 E3 S0 relates to the Kinematics M669 K0 C0:0:0:0:1 X-1:0:0:1:0 Z0:0:1:0:0 B0.22222222:0:0:0.222222222:0 ; 4 axis control -- e.g. C0 vs C0:0:0:0:1 -- wtf.

And Z4 vs Z0:0:1:0:0 -- does not compute.

[xobes]

OK, progress being made, I created some macros to reconfigure the kinematics and motor speeds to disconnect x from b and fiddle with z to break those out and deal with one at a time. In doing so, I discovered that my Z-axis motor is wired differently than my other motors, joy of joys. But I have been able to get it moving!

Here is the current state of my testing scripts:
test_macros.zip

[jyjblrd]

re: your question on why the y axis shows in the frontend, this is just an annoying quirk of reprap firmware. I guess they assume every 3d printer has a y axis lol.

[xobes]

While I've been able to test the motors individually now, (see above), attempting to call M98 P"homex.g has resulted in a problem:

working that next... I have a feeling B and X are fighting.

Also, for the Gloomy Fly-E3-PROv3 this pin diagram was helpful:https://mellow-3d.github.io/fly_e3_pro_v3_pins.html

---

Harrumph, X and B are not working (again? or ever) -- and so I'm trying to get those to home properly.

[jyjblrd]

If you get that phase shorting error, you will need to unplug and plug the board – it can not be fixed by restarting the motherboard on the web interface.

This seems to happen when the drivers configurations are changed without a power cycle, or if you try move the Y axis (which isnt mapped to anything) – stuff like that.

It is something that happened quite a bit to me while I was figuring things out (but didnt seem to actually damage the hardware). We are really stretching reprap firmware to its limits here, and I think that somewhere along the way the drivers are getting misconfigured in such a way that they give this error.

[xobes]

If you get that phase shorting error, you will need to unplug and plug the board – it can not be fixed by restarting the motherboard on the web interface.

One can recover from the "short" condition via a call to M999 (restart after being stopped by error) or M112 (full emergency stop)

[xobes]

One can recover from the "short" condition via a call to M999 (restart after being stopped by error) or M112 (full emergency stop)

Nope. Nope nope, nope. M999 will reset things to let you try again, but indeed a good old-fashioned power reset is required (at least in some cases) to prevent things from continuing to be problematic (i.e. retriggering this over and over and over).

[jyjblrd]

told you :)

It is a very transient issue, I haven't quite figured out what causes it, but i do know that a power cycle fixes it

[xobes]

Actually, if you have a relay hooked up (I do) you can use M80 and M81 to control the non-MCU devices, so this ought to help helpful for those who are starting out and debugging if there are wiring/config issues:

M80 C"PSON" ; define the pin to use and turn power on <-- goes in config.g
M81 ; turn power off
M80 ; turn power on

M81 G4 S1 M80 ; turn off, pause 1 sec, turn on

You even get a nice gui button:

But to actually clear an error, I had to M81 M999

[ehegenberger]

All ready to go but no time... :(

[jyjblrd]

With respect to X and B, I'm struggling to understand now the axis:drive mapping: M584 Z4 C0 X1 B2 E3 S0 relates to the Kinematics M669 K0 C0:0:0:0:1 X-1:0:0:1:0 Z0:0:1:0:0 B0.22222222:0:0:0.222222222:0 ; 4 axis control -- e.g. C0 vs C0:0:0:0:1 -- wtf.

We need to go from driver number (0...4) --> driver name (X,Y,Z,B,C) --> physical axes (X,Z,B,C).

The M584 command defines the driver number (0...5) --> driver name (X,Y,Z,B,C) mapping.
So the M584 Z4 C0 X1 B2 E3 S0command means that:

driver	driver
number	 name
--------------
  0	  C
  1	  X
  2	  B
  3	  E
  4	  Z

The M669 K0 C0:0:0:0:1 X-1:0:0:1:0 Z0:0:1:0:0 B0.22222222:0:0:0.222222222:0 command defines a matrix gives the driver name (X,Y,Z,B,C) --> physical axis (X,Z,B,C) mapping.
X...:...:... defines a single a row.
Therefore the command defines the matrix:

          X     Y    Z    B     C     <-- driver names
      X   -1    0    0    1     0  
      Y   -     -    -    -     -  
      Z   0     0    1    0     0  
      B   .22   0    0    .22   0  
      C   0     0    0    0     1 

      ^
physical axes

We can substitute the driver number for the driver name:

          1     -    4    2     0     <-- driver number
      X   -1    0    0    1     0  
      Y   -     -    -    -     -  
      Z   0     0    1    0     0  
      B   .22   0    0    .22   0  
      C   0     0    0    0     1 

      ^
physical axes

This means that drivers 1 & 4 2 drive the X and B axis, driver 4 drives the Z axis, and driver 0 drives the C axis.

Note that G0 / G1 commands move the physical axes by default. But if you do G1 H2 X... Z... B... C... it will move the motors according to the driver name. This is useful for if you want to move a single motor (eg. for homing)

Driver numbers can be found in the pinout image for the board.

Hope that helps. It is confusing

[xobes]

Note that G0 / G1 commands move the physical axes by default. But if you do G1 H2 X... Z... B... C... it will move the motors according to the driver name.

Per https://reprap.org/wiki/G-code#G0_.26_G1:_Move: "In RepRapFirmware, using the H1 or H2 parameter on a delta printer causes the XYZ parameters to refer to the individual tower motor positions instead of the head position," -- seems to refer to what you're saying, though their terminology isn't as precise or understandable as yours. "tower motor position" makes no sense.

I will give this a try. I can't see why I'd get any "short" indications from these motors, they are free to move in any direction as when they drive against each other that is when X moves. Additionally, I have double checked the wiring and they are wired the same as the C axis, which works. I may have to do some physical wiring changes later to prove that fact, just for sanity's sake if these commands don't work as intended.

@jyjblrd While we're on the topic, how did you arrive at 0.22?

[xobes]

This means that drivers 1 & 4 drive the X and B axis, driver 4 drives the Z axis, and driver 0 drives the C axis.

not "1 & 4" but rather "1 & 2"

[xobes]

Oh, and I'll probably figure it out here before you respond, but for posterity's sake: Is X (Driver 1) the TOP or the BOTTOM? (I.e. is B (Driver 2) the BOTTOM or the TOP motor?

[xobes]

Oh, and I'll probably figure it out here before you respond, but for posterity's sake: Is X (Driver 1) the TOP or the BOTTOM? (I.e. is B (Driver 2) the BOTTOM or the TOP motor?

Based on the kinematics, it seems that Driver 1 would have to go backwards (-1) in order for X (the arm) to move "forwards".

Some real questions, as it pertains to these terms:

Is "forward" considered CCW or CW for a given stepper motor? What orientation is said stepper motor as I am perceiving CCW or CW? What does "S1" mean in these terms in the M569 command in relation to these CCW/CW or "forward" meanings? Seems like we have half a dozen places that the meaning could flip on us.

Furthermore, the kinematics seem to again allow direction to be applied, and this begs the question as to which of these direction definitions the G1 H2 variant skips... skips kinematics, ok, sure ... skips the 569 orientation? Sure feels like it since changing Z from S0 to S1 didn't make a difference in the homing code...

Maybe I'm writing too much and making to little sense.

[xobes]

Also, is "positive" away from the center of the bed or toward the center of the bed?

[jyjblrd]

Its probably easier to figure this stuff out by plugging it all in, and then seeing where it goes and flipping the driver direction in software if necessary.

X=0 is the center of the bed

[xobes]

In order for later G-code files to have meaning, there needs to be definition.

For example, in order to use your homing algorithms, one must know that for you B was on the top and X was on the bottom:
; B (Driver 2) is TOP, X (Driver 1) is BOTTOM.

[Chuckles182]

I finally got my wiring done and can’t get my board to log into my wifi. Reading this thread is so intimidating! I’ll get it moving one day.

[xobes]

1. I still don't have my wiring done, 😉. Didn't put a limit switch on Z axis yet
2. Wi-Fi... I followed what this guy said to some degree: https://youtu.be/d9TpCkp6qHQ?si=vNSUFcf0WWSx6jM_
   I also compared the files in this repo against some new files I generated as dummy files to start with and have a Frankenstein collection of files as a result.

This approach has allowed me to specify my own settings for printer name, Web interface password, Wi-Fi said, and Wi-Fi password.

[xobes]

More info for how I set up WiFi:

runonce.g:

; runonce.g
; called after config.g. When it has been executed, it is automatically deleted!
;
; generated by RepRapFirmware Configuration Tool v3.5.0-STM32+1 on Sun Feb 02 2025 20:10:53 GMT-0600 (Central Standard Time)
M552 S0                            ; disable network
G4 S5                              ; wait half a second
M587 S"YOURSSID" P"YOURPASSWORD" ; configure WiFi
G4 S5
M552 S1                            ; enable network

Looking at the code, I don't agree with the autogenerated comments: G4 S5 is a 5 second delay, not half a second.

You could also send these commands over the serial interface, I did quite a few commands over the serial interface as well, but since I couldn't repeat commands easily (no command history, not a linux shell) I reverted to just using the web interface.

[Chuckles182]

Thanks for the help. Turns out I didn't connect the wifi antenna lol.

[xobes]

I have up on sensor less X, added a switch. My fork has the files. I also couldn't get it working.

I'm still not sure on positive/negative sense of C axis and hope to feed it the gcode propeller file from the slicer GitHub output directory later this weekend.

[xobes]

I had to reverse the order of the homing so that B was homed after X due to reliability. I'll share all my files this weekend.

…

On Sat, Feb 22, 2025 at 8:33 AM mickemajstro ***@***.***> wrote: I have succedet in X-axis not trouble in B-axis — Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZOI72YZPXXIMNY5XEUEF32RCDDLAVCNFSM6AAAAABWNDXZZCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRYGYZDGMY> . You are receiving this because you authored the thread.Message ID: <jyjblrd/Core-R-Theta-4-Axis-Printer/repo-discussions/31/comments/12286233 @github.com>

[mickemajstro]

I preaveusly put in a comment of that I did not have luck at all with sensorless homing om my printer with DUET2 WiFi MB. The biggest problem was that I tried to home to slow. I was running at 500 at first and ended up at 4000, with the Homing acceleration set att 100 in both axis.

Then it was aprox 6hour of try and error to get acc, homingspeed and sensibility to match up.