Come on, its really interesting. I want part 2
This is what Im talking about
https://duet3d.com/blog/duet3d-research-extrusion-behaviour-and-pressure-advance
Come on, its really interesting. I want part 2
This is what Im talking about
https://duet3d.com/blog/duet3d-research-extrusion-behaviour-and-pressure-advance
@adamfilip You could also try pushing the extruder motor current a wee bit higher, see if that helps. I would try to set the extrusion steps per mm for the extrusion speed you will be using the most. Who cares about 1mm/s and stuff, you wont print with that flow without a tiny tiny nozzle.
But the reality of the situation is such, that there will always be slip, you won't get perfect calibration. Even with the non-linear extrusion, the best you get is dependent on the model (tricky business), but its still open-loop control. Until proper closed loop extrusion control becomes mainstream, we are riding blind.
@lem not without making modifications to RRF so that it supplies that specific thing to the object model. as far as I understand, at least.
How are you running the mcodes in python? I could only manage to use perform_simple_code() method since it takes in a whole string. When I tried to use perform_code() I could not get any parameters to send..
in my humble opinion, this is a combination of issues, like others said.. temps seem too hot, over extrusion maybe..
BUT none of that explains the absolutely incredible geometrical deviation from your design. This is not shrinkage lol, not in this way, not in such amounts. And then it switches to reverse-shrinkage? heh...
If it was bowden related, you would expect similar defects within each layer, not a continuous geometry change over many layers.
I have a sneaking suspicion, that something is screwed up with the geometry settings of your delta. Arm length in the FW perhaps wrong.. anything related to M666 and M665
Do you have a log of what you did to the machine? Was it working well before your changes?
@3dpmicro in all honesty, PID is not the way for accurately controlling servos.. you are then talking at the very least about nested control schemes for position, velocity, acceleration, perhaps motor current.. all this is usually done in some manufacturer provided software to be adjusted. Then the question is, can they change the settings in operation? Then how to provide setpoints from the gcode for this? And I dont even know off the top of my head how to set up duet with servos haha
looks like you are talking about gain scheduling control where you "switch" between a bunch of different PID settings... Its an option, but far from the optimal one in my opinion. How many different cases are you willing to tune? Its a PITA.
@3dpmicro Im not entirely sure what you mean with your first point.
For the second one, there is something along those lines already made. This dude just made his own firmware, specifically to focus on extrusion control: closed loop with an encoder running against the filament, feedforward adjustments for temperature based on flow required, extruder slip protection, etc.. its quite awesome
https://github.com/ErwinRieger/ddprint
it should give you an idea of the amount of work and effort needed for this sort of project.
@zbeeble I'd just wait for an OG Duet, just out of principle. The incredible effort here must be supported.
@pyper I feel like @deckingman simply must be mentioned in multicolor printing, his machine is quite astonishing. If you just care for multicolor, rather than specifically having 4 IDEX's, deckingman's approach could be an option. Here's his youtubes
https://www.youtube.com/watch?v=gc8AciHjf4I
Otherwise, I'd prefer a toolchanging system a la E3D, than to cram as many gantries in the same space as possible.
Hi,
I have a .py script, that I would just run from the IDE when I was writing it (cant share it, sorry). Now I threw it into a .zip with a plugin.json, installed it. I see it on DWC, can start it, but nothing happens.
I have no DWC components, no clue how to have things show up there as of now, but since my .py script has output showing in terminal and some openCV windows starting, I expected the same to happen once I started the plugin in DWC.
In the journalctl I just see this, not very helpful.
system booted, all good
Jul 29 12:03:00 duet3 DuetControlServer[410]: [info] Starting macro file tpre0.g on channel Trigger
Jul 29 12:03:00 duet3 DuetControlServer[410]: [info] Finished macro file tpre0.g
Jul 29 12:03:00 duet3 DuetControlServer[410]: [info] Starting macro file tpost0.g on channel Trigger
Jul 29 12:03:00 duet3 DuetControlServer[410]: [info] Finished macro file tpost0.g
Jul 29 12:03:00 duet3 DuetControlServer[410]: [info] Finished macro file config.g
Jul 29 12:08:58 duet3 DuetControlServer[410]: [info] System time has been changed
my plugin started through DWC, journal throws this error continuously
Jul 29 12:10:44 duet3 DuetControlServer[410]: [warn] IPC#22: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:10:47 duet3 DuetControlServer[410]: [warn] IPC#23: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:10:50 duet3 DuetControlServer[410]: [warn] IPC#24: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:10:53 duet3 DuetControlServer[410]: [warn] IPC#25: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:10:56 duet3 DuetControlServer[410]: [warn] IPC#26: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:10:59 duet3 DuetControlServer[410]: [warn] IPC#27: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:11:02 duet3 DuetControlServer[410]: [warn] IPC#28: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:11:05 duet3 DuetControlServer[410]: [warn] IPC#29: Client with outdated protocol version connected (got 11, want 12)
Jul 29 12:11:08 duet3 DuetControlServer[410]: [warn] IPC#30: Client with outdated protocol version connected (got 11, want 12)
My plugin stopped in DWC
Jul 29 12:11:11 duet3 DuetControlServer[410]: [error] IPC#32: Failed to find plugin permissions for pid #1296
Jul 29 12:11:11 duet3 DuetControlServer[410]: [warn] IPC#32: Terminating connection due to insufficient permissions
The permission part I don't get, they are defined in the plugin.json file:
(there is more than I need for sure)
{
"id": "My First Plugin",
"name": "MyPlugin",
"author": "Me",
"version": "1.0.0",
"license": "MIT",
"homepage": "redacted",
"dwcVersion": "3.4",
"sbcDsfVersion": "3.4",
"sbcRequired": true,
"sbcExecutable": "my_script.py",
"sbcExecutableArguments": null,
"sbcOutputRedirected": false,
"sbcPackageDependencies": [],
"sbcPythonDependencies": [],
"sbcPermissions": ["objectModelReadWrite","gpioAccess", "fileSystemAccess", "commandExecution", "launchProcesses"]
}
I tried to stop DCS and restart in debug mode
sudo /opt/dsf/bin/DuetControlServer -l debug -r
but Im not sure what this is supposed to do, DWC does not reconnect and the terminal just continues this sort of output. I cant even stop DCS again anymore, starting after stop says another is still running, but DWC says its not started.... ugh. I have to restart everything to DWC be able to connect again.
[info] Settings loaded
[info] Environment initialized
[info] Connection to Duet established
[info] IPC socket created at /run/dsf/dcs.sock
[debug] Updated key limits
[debug] Requesting update of key boards, seq 0 -> 363
[debug] Updated key boards
[debug] Requesting update of key directories, seq 0 -> 0
[debug] Updated key directories
[debug] Requesting update of key fans, seq 0 -> 8
[debug] Updated key fans
[debug] Requesting update of key global, seq 0 -> 0
[debug] Updated key global
[debug] Requesting update of key heat, seq 0 -> 12
[debug] Updated key heat
[debug] Requesting update of key inputs, seq 0 -> 20
[debug] Updated key inputs
[debug] Requesting update of key job, seq 0 -> 2
I dont know how to proceed figuring this out.
Come on, its really interesting. I want part 2
This is what Im talking about
https://duet3d.com/blog/duet3d-research-extrusion-behaviour-and-pressure-advance
@ravs99 I am not sure if you could accomplish your goal with macros only. If not, then you need firmware modifications (could be easy for you if you are good in C++). But it definitely is very doable when using SBC with Duet, then you can just code up a python script that will read your sensor and send commands to the stepper.
@petriheino if you have a high micro-stepping value its even easier to skip steps because of decreasing holding torque