Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tighter Hangprinter Compatibility #186

Open
wants to merge 49 commits into
base: v2-dev
from

Conversation

Projects
None yet
2 participants
@tobbelobb
Copy link

tobbelobb commented Jun 29, 2018

I updated the Hangprinter kinematics using the equation derived here:
http://vitana.se/opr3d/tbear/2017.html#hangprinter_project_29

Best regards,

@tobbelobb tobbelobb changed the title Hangprinter Line Buildup Compensation Tighter Hangprinter Compatibility Jul 5, 2018

@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Jul 5, 2018

The now enormous HangprinterKinematics::Configure method should probably be split up, so that FORMAT_STRING_LENGTH can come back down to 256.

One suggestion is to move 'R' (spoolRadii), 'G' (motorGearTeeth), 'H' (spoolGearTeeth), and 'J' (fullStepsPerRevolution) parameters to M92, as they could be used to calculate stepsPerMm on other types of kinematics as well.

@dc42

This comment has been minimized.

Copy link
Owner

dc42 commented Jul 5, 2018

Thanks for all your contributions. I am currently on holiday so I will review and action your contributions when I return.

@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Jul 5, 2018

Hi David! Tony has notified me that you're away. I hope you have a wonderful holiday. My own starts on Monday.

When you're back, don't hesitate to throw things around if I've gone against code norms, principles, or best practices. I have relatively little experience with C++ and object oriented code.

Posting my todo here in case you get curious when I'm away and unavailable:

  • G95 like here: Marlin_main.cpp. Maybe send "G95" in ascii, not 95 as hex (0x5f) as I've done in Marlin.
  • G96 like here: Marlin_main.cpp.
  • M114 S1 or a better solution for collecting encoder data.
  • Geometry sanity check on anchor location configuration like here: SanityCheck.h.
  • Milestone reached: Marlin feature parity.

The i2c usage in itself creates a wish-list

  • Adjustment of M569, so we can do
M584 A5 B6 C7 D8 ; This should already work
M569 P5 I0x0a  ; Configure driver 5 to be external, connected with i2c address 0x0a
M569 P6 I0x0b  ; Configure driver 6 to be external, connected with i2c address 0x0b
...

or maybe better

M569 PA I0x0a  ; Configure machine axis with the name A to be external, connected with i2c address 0x0a
...

Gcodes that should be forwarded to external drivers via i2c:

  • M906 (set motor currents). Adjusts Mechaduino iMAX.
  • M350 (set microstepping). Adjusts Mechaduino stepangle.
  • Also M301 (Set PID parameters) should get a D-parameter, so Mechaduino PID tuning can be done with gcodes from Duet Web Control. It would look like:
M350 D5 P15.0 I0.2 D250.0 ; PID tune the motor connected to driver 5

The Mechaduino-side variables are called pKp, pKi, pKd.

  • The Mechaduino code that handles received i2c: Utils.cpp. There's also giveAngle() that is called upon i2c request. Used during M114 S1.
  • Test with motors and heaters attached. It will probably be August before I get here...
@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Jul 6, 2018

G95 support check.

Mechaduino side of G95 (and G96) here: Gitlab commit. I created a branch called RepRapFirmware_compatibility to dev on until code is tested on hardware.

@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Jul 8, 2018

G96 and M114 S1 also check but untested on hardware.

@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Aug 17, 2018

The Hangprinter code (excluding the Mechaduino related code) has been tested and works. See Michael Delay's post here: https://www.facebook.com/groups/hangprinter/permalink/428191971024301/

@tobbelobb tobbelobb force-pushed the tobbelobb:v2-dev_hangprinter branch from a335bd7 to 3ae6b4a Oct 22, 2018

@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Oct 23, 2018

Hi @dc42 I'm working on how to move the Hangprinters individual axes (G1 S1 and G1 S2).

I've noticed that they always call InverseTransform, and that this triggers some problems:

The sqrtf here sometimes get negative arguments, so we need to guard it with a fabs:

machinePos[2] = (- halfB - sqrtf(fsquare(halfB) - A * C))/A;
I haven't yet backtracked if this still leaves the equations valid.

With default anchor positions, the values Yab, Ybc, Yca, Zab, Zbc, Zca, P, P2, Q, R, U, and A all become equal to zero. This leads to division by zero errors down again once InverseTransform is invoked.

Both of the above problems leads to NaNs being stored in machinePos. The NaNs causes the DuetWifi to reboot when they're sent to the web interface. Debugging through serial does not reboot the board.

Inserting the fabs guard and using different anchor position parameters lets me use G1 S2. However, since G1 S2 will mostly be used when lines are slack we'd prefer if MotorStepsToCartesian (which calls InverseTransform) is not called at all after individual motor moves. We'd rather leave all internal counters untouched after a nonzero movetype move.

Does RRF have a mechanism for storing and retrieving machine state, or should I go for trying to avoid touching counters by wrapping the lines where they are incremented? In Marlin I used if (count_this_move) statements, would this make sense in RRF as well?

I will get around these problems of you don't have the time to help me, but your input would be very valuable. Thanks.

@tobbelobb tobbelobb force-pushed the tobbelobb:v2-dev_hangprinter branch from b2faf84 to df537da Nov 24, 2018

tobbelobb added some commits Jun 27, 2018

Syncs MachineAxisNames() with new machineAxisLetters field in GCodes …
…object, which is put to use in M589 M92 M201 M906 M203 M208 M350 M566. Also increases FORMAT_STRING_LENGTH to 1024.
Adds i2cValues, set per driver with M569 P<driver> I<i2c addr> so cer…
…tain gcodes can be passed on to external driver connected via i2c.
Make 201 and 203 return to XYZ parameters since SetAcceleration and S…
…etMaxFeedrate expect per gcode cartesian values, not per motor values

@tobbelobb tobbelobb force-pushed the tobbelobb:v2-dev_hangprinter branch from df537da to 24eb183 Nov 24, 2018

@tobbelobb

This comment has been minimized.

Copy link
Author

tobbelobb commented Nov 29, 2018

Hi @dc42 . I've done my first attempts at talking to the second ODrive via SERIAL_WIFI_DEVICE (the tx/rx on the EPS_COMMS header), but I'm not able to establish the connection.

So I read in the schematics and found a note: "J34 not populated in production boards".
Does this mean that I will never be able to use the UTXD1/URXD1 pins to control my second ODrive?

tobbelobb added some commits Dec 3, 2018

WIP: Trying to reconfigure shared SPI pins to UART
TODO:
   Put up guards at M918, M305 (if X within [150,308])
   and M569 (if channel is 99) entry points.
   M569 Q1:99:115200 will now set up pins 26 and 27 as UART tx/rx.
   M918 and M305 will try to set them up as SPI MISO/MOSI.

 - Make commsInitDone a shared flag between the three Mcodes.

 - Create new flags that indicate if pins 26 and 27 are in Spi mode
   or UART mode.

 - Only allow M918 and M305 P<num> X[150,308] if 26&27 not in UART mode.
   Set the SpiModeFlag inside those gcodes.

 - Only allow M569 Q<num>:99:<baud> if 26&27 not in Spi mode.
   Set the UARTModeFlag inside that gcode.

 - Do not call Display::Spin() from RepRap::Spin().
   Instead, wait for M918, then call Display::Spin().

 - Only call Display::Exit() from RepRap::Exit() if pins 26 and 27
   are in Spi mode.

 - Only perform Display::UpdatingFirmware if 26&27 in Spi mode.
WIP: Protects Sspi and stolen Uart from each other
But leaves most of the responsibility to the SharedSspi driver...

@tobbelobb tobbelobb force-pushed the tobbelobb:v2-dev_hangprinter branch from 2e52a1e to 4015705 Dec 13, 2018

tobbelobb added some commits Dec 15, 2018

Makes origin ref point of motor pos and buildup
Having the origin as motor position point of reference makes
the buildup compensation equations simpler.

Spool buildup reference point is set to the origin as well.
So spoolRadii-values (M669 R) is assumed to include the
buildup that is on spools when nozzle at origin.

The common reference point makes the buildup
compensation equations simpler yet.

Behaviour changes:
 - M114 motor pos print outs gets easier to interpret
 - Users should no longer configure mountedLine (M669 W)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.