@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
@jens55 I have PLA spools sitting out for months, left on the printer, so theres like 0.5-0.7m of unwound filament. I have never ever seen such behavior where it would develop visible cracks on its own... Only seen PLA become really brittle presumably from absorbing moisture, but even then it looked fine, until you touched it haha.
PLA can be oxidized and it does reduce its molar mass, meaning it becomes more brittle and weaker, but I've only seen studies pointing out that this is an appreciable effect at 70ish degrees C, not so much below that point.
Could it be that you have some chemical vapor producing items nearby?
@dad003 How did this print so well at 200 lol. I run petg at 230 as well (slow speeds, high volume)
Interesting that it looks fairly shiny. Cold prints (in petg and pla at least) usually turn out a bit matte on the surface, not shiny at all. And they are weak as hell in the layer bonding.
Are you sure your hotend thermistor is set up well?
@kengoodhope did you try the OG duet board in standalone mode? If it works without SBC you can at least rule out the duet as a point of failure, I think
As I understand you see the user interface (duet web control)? Have you defined your macro .g files for homing? Duet wont let you move until homed unless you specify it with M564
I only quickly glanced over the config, didnt see anything bad
Try to type in console:
M564 H0 S0
The above code will let you move without homing and also it will ignore axis limits (can move to X -10 for example). Be careful, just try to get things moving in small distances, try something like:
G1 X5 F300
This will move X axis 5mm in the positive direction at 300 mm/min speed (very slow).
Could you provide more details on what your scanner will do, how it will work, what is doing the scanning? Just some touch probe or is it laser based or something?
@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.
Can anyone explain why the parameters do not get executed when using the perform_code() method? This is the only way I managed to get this to send successfully:
from dsf.connections import CommandConnection
from dsf.commands.code import Code
from dsf.commands.code import CodeFlags
from dsf.commands.code import CodeType
from dsf.commands.codeparameter import CodeParameter
def send_code():
command_connection = CommandConnection(debug=True)
command_connection.connect()
instance = Code("Code")
instance.Type = CodeType.MCode
instance.MajorNumber = 106
instance.parameter = CodeParameter('S', 255)
instance.Flags = CodeFlags.Asynchronous
It sends, responds with success, but nothing happens, fan speed does not change, but commands with no parameter work fine, such as G28, or T0 etc.
send: {"command":"Code","Type":"M","MajorNumber":106,"parameter":{"letter":"S","string_value":"255","_CodeParameter__parsed_value":255,"is_expression":false},"Flags":1}
recv: {"success":true}
@mac from the video it sounds like stepping issues, like if it was low current with way too high rpm.
But looking at this thread (wtf how is this 500+ replies in a few days 
) im inclined to believe that has been thoroughly looked over in the config.g?
And then I'd still look at the basics again before anything else. Is everything really wired properly.. I swear for me thats the issue 70% of the time
@chrishamm thanks for the snip, helps with understanding (there are no methods like "Type" or "MajorNumber" defined under Code class so I had no clue this was possible). But I do not understand what you mean by "make sure pi is part of dsf group"
A problem though.. to make a Code() class instance, one must provide a command argument, which is supposed to be a string.. then the same issue with "NoneType has no attribute sendall" being not there happens, as the screen in my last post shows.
Ok so I missed the damn brackets after command_connection.connect ()
Code instance still requires a command string, but In test_custom_m_codes.py I saw this
so I tried specifying command string as "Code"
instance = Code("Code", Type='CodeType.MCode', MajorNumber=115)
and it works!
I got my stuff working with send_simple_code, but damn the send and receive output is flooding my terminal. So I want to know how to use send_code() just to stop the responses, increased performance is just a bonus haha.
Call me dumb, I cant figure out how to do this with python-dsf...
from dsf.connections import CommandConnection
from dsf.commands.code import Code
from dsf.commands.code import CodeFlags
com = 'M115'
def send_code():
command_connection = CommandConnection(debug=True)
command_connection.connect
instance = Code(com)
test = CodeFlags
test.Asynchronous
try:
command_connection.perform_code(instance)
finally:
command_connection.close()
if __name__ == "__main__":
send_code()
I thought this is what @chrishamm was saying, I still dont see how CodeFlags is playing a role here, but I get this when trying the above
halp? How can I debug what is going on in DCS? I tried
sudo systemctl stop duetcontrolserver
sudo /opt/dsf/bin/DuetControlServer -l debug -r
but then DWC does not connect anymore saying DCS is not started, and the terminal is just showing this "updated key boards" over and over, does not seem to end
just goes on and on
@olflappy all these have been done in research. In one case they even resliced the model on the go, based on the height error (from a laser profilometer). They had something like an rtx2070 doing the online reslicing lol. It was a BAAM printer though. All of these things are great in theory, but making them viable in practice and on any printed geometry, not just some research test-sample rectangular block, is a whole different issue.
Also photogrammetry was also investigated. It sucks. Structured light projection, speckle patterns and laser profilometers are all miles better.