Posts made by GizmotronX5000

Wow! Very cool. Where can we find out more about this build?

Thanks for the tips! I was thinking I might do something like that. For the cylinder it would make sense to unwrap it and design a rectangular STL part and wrap it back onto the cylinder. Getting rid of the seam seems difficult though.

I'm building a new Duet powered machine and I'm attempting to 3D print on a rotating mandrel, kind of like a rotational axis engraver in reverse. I believe I can modify the firmware to do this by taking pieces of code from the polar printer kinematic profile, but slicing is going to be the hold up. For simple test cases I probably won't even have to modify the firmware.

I did a quick search online and I haven't seen anybody solve this, but I bet people have tried this before and I just haven't found it.

I see two paths forward.

1. Start from CAM and trick the software into thinking I have an engraver, then post process the G-code to add extrusions or whatever I need. CAM will probably handle the motion more easily, but not the extrusion.

2. Start with slicing to handle the extrusions and other printing parameters, but post process the G-code to account for the new kinematics.

Either seems possible, but I'm not familiar with much CAM, so I'm hoping for some input.

Edit:
This is a similar question to this thread, but slightly different I think. Looks like there is some interest.
https://forum.duet3d.com/topic/13964/using-a-4th-rotary-axis/

or should I being doing something similar to rotary delta with segmented motion? Is that a valid work around? I could change all axes to be linear axes, but use segmented motion instead in the constructor. Would I need to change anything else if I tried that?

I just tried this to see what might happen. I changed my kinematics class to:
MyKinematics::MyKinematics() : Kinematics(KinematicsType::myKinematics, DefaultSegmentsPerSecond, DefaultMinSegmentSize, false), numTowers(UsualNumTowers)
{
Init();
}

I took the definitions of the defaults from rotary delta kinematics, 100, and 0.2 respectively

I also changed GetMotionType to:
MotionType LinearDelta7DKinematics::GetMotionType(size_t axis) const
{
return MotionType::linear;
}

Things mostly work now, but the motion is not entirely smooth. It is definitely trying to approximate a straight line, but not quite right. As far as I can tell all of the moves do at least arrive in the correct spot.

@dc42 said in Update on delta motion in custom kinematics class:

I think you may have been right anout those lines in DDA.cpp that you highlighted, specifically this one:

params.dparams = static_cast<const LinearDeltaKinematics*>(&(reprap.GetMove().GetKinematics()));

The static_cast is wrong in your case, because the kinematics is your own class, not the LinearDeltaKinematics class.

One possible solution may be to derive your own kinematics class from LinearDeltaKinematics.

Ooh boy. I'm really getting into it now aren't I? Derived classes sound familiar, but I should've taken more than 1 class of C++ in school. I'll look into that. Do you have any pointers on how to start? Are there any derived kinematics classes already in this project I can work from to understand? Thanks again.

I updated to version 2.03RC1, and the same thing happens. The only thing I really changed was added an override function of GetLinearAxes(), which doesn't seem to do anything yet. I copied the one from LinearDeltaKinematics. Looks like that is in the pipeline though, so I'll pay attention to that going forward.

Is my constructor correct to be:

MyKinematics::MyKinematics() : Kinematics(KinematicsType::myKinematics, -1.0, 0.0, true), numTowers(UsualNumTowers)
{
Init();
}

or should I being doing something similar to rotary delta with segmented motion? Is that a valid work around? I could change all axes to be linear axes, but use segmented motion instead in the constructor. Would I need to change anything else if I tried that?

@danal Agreed, it's always good to check the basics. I am sure that I'm adjusting the machine position, not the motor position. I'm not confident that my kinematics class is 100% configured right, but all of the motion I need works. The "implied" moves of the delta all happen properly, except that the special case delta straight line motion doesn't work; the print head travels in an arc.

Here is a list of my modifications so far to the firmware, which work.

I had to modify the GCodes2.cpp file for M665 first. It kept forcing my printer into KinematicsType::linearDelta when it saw an M665 command, so I added another case for my kinematics class number. This work fine and M122 reports back that I am in the right mode, plus my transformations happen correctly, so I know the right mode is being used.

I copied LinearDeltaKinematics.h/cpp and created my own versions, modifying Recalc(), the various forward/inverse transform functions, CartesianToMotorSteps() and MotorStepsToCartesian(), removed basically any function relating to auto calibration (for now until I figure out a way to add them back if I get to it).

I've created homing files for everything, and configured the extra axes in config.g

I also use:
MotionType LinearDelta7DKinematics::GetMotionType(size_t axis) const
{
return (axis < numTowers) ? MotionType::segmentFreeDelta : MotionType::linear;
}

At this point the motion all works for small movements. If I could force my slicer to only make <2mm moves I would be set. Up to this point it makes sense that the print head travels in an arc because I haven't told Move to treat it as a delta.

In an attempt to fix the segmentFreeDelta motion I made these additional changes that have not worked:

In Move.h:
bool IsDeltaMode() const { return (kinematics->GetKinematicsType() == KinematicsType::linearDelta) || (kinematics->GetKinematicsType() == KinematicsType::myKinematics); }

This causes all of the motion involving the 3 delta axes to be jumpy and inaccurate for all moves that aren't purely Z. The extra linear axes all work fine still, but the delta no longer tracks the V axis motion like before. I'm sure something in my kinematics class could be causing this, but it seems odd that the motion works fine when I treat all axes as linear and breaks when I try to incorporate the delta motion type.

I know this is very weird case. Thanks for all the help, I really appreciate it.

I'm actually using 2.03beta2 so not crazy old, but behind the current version. I'll update today.

I think you mean that when you include V20 in a move, you want to implicitly add Y-20 so that the belt motion won't affect the print. That does indeed mean that you need new kinematics, unless you preprocess the GCode to add or adjust the Y coordinates when V movement is present.

That's a good way of putting it. That's pretty much exactly what I've done. By performing a series of coordinate transformations within the kinematics class I have made my G code processing much easier. Basically I can print standard G code and the transformations keep track of the proper coordinate system.

My GetMotionType function is

MotionType LinearDelta7DKinematics::GetMotionType(size_t axis) const
{
return (axis < numTowers) ? MotionType::segmentFreeDelta : MotionType::linear;
}

I am only using 3 delta axes and configuring them with M665 R110.6 L340.5 B90 H120.35, which should set numTowers to 3.

Thanks for the reply. I'm sure I am wrong about the problematic lines. I just tried following isDeltaMode until I stopped seeing things that made sense to me.

Unfortunately I don't think I can use the standards Delta kinematics because when I make a movement using one of the extra axes often the Delta axes must move too. For instance, a movement of G1 V20 moves the print bed 20mm in the +Y direction. My kinematics class allows the Delta printer to track that movement without needing a G1 Y20 movement as well. This way I can use regular G Code to print on a moving surface.

I will double check today if I implemented the motion type correctly for my axes today, but I think I have.

Everything works great, but the Delta moves in arcs. I've been trying to make sure I only do small movements, but lately I've had trouble getting prints started if they have straight edges because the G Code points are far apart and in between points the nozzle jams into the print surface.

I will try adding additional axes using the M command. I saw that in the last update but since my class was working (minus this problem) I didn't try that.

Re: Segment free delta motion in custom kinematics class

Version 2.03beta2

I've finally had some time to look into this behavior a bit more. I think I've identified some of the lines that might be causing trouble. I'm using this in a way that I'm sure isn't intended, but essentially I have a 7 axis system, where 3 of the axes consist of a delta printer. The rest of the axes move the printer itself, so I have a custom kinematics class to account for that.

Essentially how it would work best in my case is if the segment free delta movement of the delta axes worked even while other axes were moving. I've complicated it a whole lot by making the delta axes dependent on other linear axes. Think delta printer over a conveyor belt. As axis V moves (linear motion of the print bed relative to the print volume) I make the delta track its position above the build surface so it can continue printing using normally sliced G-code, with a few modifications to add V-moves. In this way, motion of the delta tower axes can be caused by movement of a different axis. The kinematics works, but the delta doesn't move in a straight path.

The problem I'm running into is that I can no longer make the delta printer use segment free delta movement, so all large movements are arcs.

I changed the line in DDA.cpp where it calls IsDeltaMode() so that it is true for my class as well, but that creates a new problem. Whenever the printer moves it jerks around towards where it is supposed to go, but never smoothly, and not always to the correct final position.

I'm sure that the delta movement portion of the code assumes only 3 axes, which is a natural assumption to make.
Possibly lines 1118-1132 in DDA.cpp might be causing trouble? I'm not entirely sure where to go from here.

@dc42 Awesome. I'll try that out and report back.

I doubt that it would make sense to generalize the delta kinematics to my case. I'm adding an extra cartesian Z axis to the system, much like the reserved kinematics I see (Hopefully it goes somewhere this time around). I was able to change the IsDeltaMode() function to return true for my mode, but now the system stutters and doesn't finish any X or Y movements. Z movements work fine, and the extra axis works too.

I should also mention that I'm on version 2.02 right now, if that affects this at all. I will update to 2.03 releases, but I haven't yet.

I'm working on a custom delta printer with custom kinematics and I've created a copy of LinearDeltaKinematics that I'm modifying. For the most part it works great, but I've noticed that in various places the delta printer movement is hard-coded into the firmware. Because I'm not using KinematicsType 3 this special movement doesn't happen. Because of this my custom delta moves in non-linear paths.

Is it possible to get a solution to this? I think I could get around it by replacing the standard LinearDelta class with mine, but that's not ideal.

I saw that there have been a lot of tweaks and updates to the kinematics classes lately, so now seemed like a good time to bring this up.

@dc42 I have noticed that the error will start for me sometimes after touching the printer. I do not have ground wires on the casings of my stepper motors right now. Occasionally I will get a static shock and the error occurs. (Can't confirm 100% that this is directly the cause, but it seems possible)

When I am working on the printer it is much more likely to occur than when I am just letting it run.

@dc42

1. M122
   === Diagnostics ===
   RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
   Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
   Used output buffers: 1 of 20 (14 max)
   === RTOS ===
   Static ram: 25524
   Dynamic ram: 98292 of which 0 recycled
   Exception stack ram used: 384
   Never used ram: 6872
   Tasks: NETWORK(ready,544) HEAT(blocked,1232) MAIN(running,3812) IDLE(ready,200)
   Owned mutexes:
   === Platform ===
   Last reset 00:16:58 ago, cause: power up
   Last software reset at 2019-01-23 14:44, reason: User, spinning module GCodes, available RAM 6776 bytes (slot 3)
   Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
   Error status: 0
   Free file entries: 10
   SD card 0 detected, interface speed: 20.0MBytes/sec
   SD card longest block write time: 15.9ms, max retries 0
   MCU temperature: min 31.3, current 31.5, max 31.9
   Supply voltage: min 12.0, current 12.3, max 12.4, under voltage events: 0, over voltage events: 0, power good: yes
   Driver 0: standstill, SG min/max 37/510
   Driver 1: standstill, SG min/max 70/544
   Driver 2: standstill, SG min/max 63/552
   Driver 3: standstill, SG min/max not available
   Driver 4: standstill, SG min/max not available
   Driver 5: standstill, SG min/max not available
   Driver 6: standstill, SG min/max 0/462
   Driver 7: standstill, SG min/max 0/0
   Driver 8: standstill, SG min/max 0/0
   Driver 9: standstill, SG min/max not available
   Date/time: 2019-01-23 15:17:17
   Cache data hit count 4294967295
   Slowest loop: 59.17ms; fastest: 29.15ms
   I2C nak errors 0, send timeouts 63402, receive timeouts 0, finishTimeouts 63402
   === Move ===
   Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 237, MaxWait: 181633ms, Underruns: 0, 0
   Scheduled moves: 21, completed moves: 21
   Bed compensation in use: none
   Bed probe heights: 0.000 0.000 0.000 0.000 0.000
   === Heat ===
   Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
   Heater 0 is on, I-accum = 0.0
   Heater 1 is on, I-accum = 0.0
   === GCodes ===
   Segments left: 0
   Stack records: 1 allocated, 0 in use
   Movement lock held by null
   http is idle in state(s) 0
   telnet is idle in state(s) 0
   file is idle in state(s) 0
   serial is idle in state(s) 0
   aux is idle in state(s) 0
   daemon is idle in state(s) 0
   queue is idle in state(s) 0
   autopause is idle in state(s) 0
   Code queue is empty.
   === Network ===
   Slowest loop: 63.08ms; fastest: 0.03ms
   Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
   HTTP sessions: 1 of 8
   Interface state 5, link 100Mbps full duplex

2. The Duex5 endstops do not work as I had previously thought. The endstops on the Duet work, but not the Duex5.

3. M122 right after pressing the endstops a few times (most lines removed):
   M122
   Date/time: 2019-01-23 15:18:05
   Cache data hit count 4294967295
   Slowest loop: 59.10ms; fastest: 0.08ms
   I2C nak errors 0, send timeouts 4797, receive timeouts 0, finishTimeouts 4797

4. No fans are actually connected to the Duex5, so I can't test this. I can configure a dummy fan to the Duex5 for next time though. All fans on the Duet work fine.

5. M122 (after messing around with duet fans)
   Date/time: 2019-01-23 15:22:28
   Cache data hit count 4294967295
   Slowest loop: 59.11ms; fastest: 0.08ms
   I2C nak errors 0, send timeouts 17551, receive timeouts 0, finishTimeouts 17551

6. No changes. Just sending M122 every few seconds.

M122
Date/time: 2019-01-23 15:23:31
Cache data hit count 4294967295
Slowest loop: 59.11ms; fastest: 29.47ms
I2C nak errors 0, send timeouts 10480, receive timeouts 0, finishTimeouts 10480

M122
Date/time: 2019-01-23 15:24:00
Cache data hit count 4294967295
Slowest loop: 59.10ms; fastest: 29.46ms
I2C nak errors 0, send timeouts 4900, receive timeouts 0, finishTimeouts 4900

M122
Date/time: 2019-01-23 15:24:42
Cache data hit count 4294967295
Slowest loop: 59.10ms; fastest: 29.47ms
I2C nak errors 0, send timeouts 6885, receive timeouts 0, finishTimeouts 6885

I'm assuming the error count starts over each time I send M122. But the number is constantly changing. The lowest I saw was 195 from sending M122 back to back as fast as I could manually from the console. Looks like about 160-170 errors per second on average (164 seems to be the usual) regardless of what commands I send or which endstops I press.

Edit:
I let it idle in this state for about 15 minutes. The average was 166.2 errors per second. It's very consistent.

@dc42 Can do. It doesn't happen often, but the next time it occurs I'll be sure to reply here with that information.

I was under the impression that when the problem occurs, no I2C commands get through at all. Do you have any evidence that any I2C commands are getting through? I2C commands are needed to set the fan RPM and to read the endstops. They are not needed to drive the motors or the heaters.

When I get this error, everything still works, including Duex5 endstops for homing. I haven't tried changing fan RPM during this error though.

It finally happened again after a few hours of testing.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 1 of 20 (17 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98292 of which 0 recycled
Exception stack ram used: 416
Never used ram: 6840
Tasks: NETWORK(ready,544) HEAT(blocked,848) MAIN(running,3844) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 02:23:39 ago, cause: power up
Last software reset at 2019-01-15 15:38, reason: User, spinning module GCodes, available RAM 4216 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 8
Free file entries: 8
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 41.0ms, max retries 0
MCU temperature: min 33.1, current 33.6, max 35.0
Supply voltage: min 11.4, current 12.3, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max 7/594
Driver 1: standstill, SG min/max 0/659
Driver 2: standstill, SG min/max 10/602
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max 0/492
Driver 7: ok, SG min/max 0/0
Driver 8: standstill, SG min/max 0/0
Driver 9: standstill, SG min/max not available
Date/time: 2019-01-17 17:24:08
Cache data hit count 4294967295
Slowest loop: 248.05ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 28776, receive timeouts 0, finishTimeouts 28776
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 239, MinFreeDm: 104, MaxWait: 1342116ms, Underruns: 0, 0
Scheduled moves: 64, completed moves: 63
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.9
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 1 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is idle in state(s) 1 5
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 87.35ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex

Some good news, some bad. When I do I get I2C errors now the printer performs a few moves, stops, and does a few more moves. Previously it would only do one move.

Unfortunately I reset it before thinking to grab a screenshot of M122. Here's a recreation. I'll get the real thing next time it happens.

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DDM-9FAM2-LW4SD-6J9F2-3S46R-K2XBW
Used output buffers: 3 of 20 (14 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98292 of which 0 recycled
Exception stack ram used: 352
Never used ram: 6904
Tasks: NETWORK(ready,544) HEAT(blocked,1232) MAIN(running,3844) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:04:18 ago, cause: power up
Last software reset at 2019-01-15 15:38, reason: User, spinning module GCodes, available RAM 4216 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 32.7, current 32.9, max 33.5
Supply voltage: min 11.6, current 11.7, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2019-01-17 15:04:48
Cache data hit count 645630772
Slowest loop: 94.64ms; fastest: 0.08ms
I2C nak errors 0, send timeouts 12345, receive timeouts 0, finishTimeouts 12345 (something similar to this)
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 25, completed moves: 25
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by file
http is idle in state(s) 0
telnet is idle in state(s) 0
file is doing "M190 S65 " in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 11.51ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 2 of 8
Interface state 5, link 100Mbps full duplex

The next time it happens I'll be sure to grab the real M122 output. It has been a while since I posted, but we've been through all of the usual troubleshooting as far as I know. I also saw that the I2C communication was redone for 2.02, which is why I am bringing this up.

Yep, that was the problem. I knew it was going to be something simple I was forgetting. I added single quotes around the file names in the post-build step and it worked. Thanks for the help.