Hey, so the right way to implement this for skew is with the M556 command I believe. It will only need the X argument as it's only XY compensation that we are doing with this model. I have a v4 of the calculator that I have sent to one use to test to see if my calculations are working correctly as I don't have a duet printer running at the moment.
For the shrinkage and step/mm that are either slicer based, or done using the obvious config file modification.
@dc42 Perfect, this is exactly the thing. Thankyou!
Through recent experiments with extrusion i've come across a strange issue with minimum extrusion rates and unsure which parts of the system causes it.
As you can see from the chart below. The target extrusion time for all tests was 5 seconds but only tests 7 onwards lasted for 5 seconds as others seem to hit minimum extrusion limits and were sped up to 1.2mm³/s and thus completed faster.
Seems like its still plenty fast enough for a stepper motor. interpolation is enabled so there are plenty of microsteps available. I'm pretty stuck for ideas where this could be coming from.
G-code and firmware attached below.
config.g
Low Flow Limit Test.gcode
@adam-v3d the node was the DSF monitor node.
@mintytrebor no sorry that was wifi, i didn't expect wifi to be good.
@adam-v3d Gave the node red thing a pretty good shot today, spent some time learning how it works and managed to get it working and sending back data. In the current state I have it, on a 200ms request, it take anywhere from 227ms to over 1600ms to get a response when idle and also seems to be crashing the duet quite often too which would make the test void so going to abandon that idea. Currently I can get reading every 25.5ms +-0.5ms with the arduino and would like to keep that kind of rate and precision where possible.
I got some new level shifters that seem to work a bit better so i'm going to give the direct serial connection another go and also try with the arduino mega if It doesn't go well with the uno.
@mintytrebor I've just installed and had a little look at this. I quite like it and might be more my speed but don't understand it really yet. It looks like it'll be capable of polling the arduino and duet at the same time and just merging them into a single file on the pc which could be useful. Maybe also a powerful option for when i'm adding more features later down the line.
Are you able to share details on what you showed here?
@sindarius Oh i did get the thing with pins 8 and 9 after realising what the library was for and that the designated TX and RX pins are basically the same serial i'm using to connect to the laptop.
For connection, do you connect duet TX to pin 8, and duet RX to pin 9?
@mintytrebor This is cool, I guess its easy when you know how. I've never used this before though and not sure how I would sync it up with the other data from the arduino.
@sindarius I think I kind of understood most of the code, only little bits of syntax I didn't understand. I turn on debugging and the end result was that it either paused completely after 500ms (first time it polled the duet) or ran mostly correctly but hotend temps and fan always showed the original values in the library of 10, 285 etc.
I guess this means there was no data coming from the Duet. Maybe wrong port number. I used M575 P1 B57600 S0 and connector to the RX and TX on the Panel due 4 pin connector next to the 4 pin probe connector.
@adam-v3d Switching my connection on pins 8 and 9 has changed things. This might be whats going on. More errors now, but different ones at least...
@gixxerfast Im using a genuine Arduino. I have two elegoo clones too, but they are all labelled the same.
I have discovered from doing this that the RX and TX dedicated pins (0 and 1) seem to be the same as what is used to communicate with laptop via USB so the connection to the duet is using AltSoftSerial which is a library that adds software serial connection using pins 8 and 9 on the arduino.
Whats confusing me at the moment is that in duet.h there is this:
private:
void ProcessBuffer();
int bufferIdx;
byte* buffer;
DynamicJsonDocument doc;
#ifdef SOFTWARESERIAL
AltSoftSerial duetSerial; //Software serial on pins 8/9 on Arduino Uno.
#endif
};
Which is about the json called doc which should hold all the data from the duet.
At the bottom of this:
void DuetData::ProcessBuffer()
{
//Process the json data
Status = DUET_STATUS::UNKNOWN;
//Scan for invalid characters
for (int i = 0; i < bufferIdx - 1; i++)
{
if (buffer[i] < 32 || buffer[i] > 126)
{
#ifdef DEBUG
Serial.println("Throwing out buffer due to bad characters");
#endif
return;
}
}
DeserializationError error = deserializeJson(doc, buffer);
if (error.code() != error.Ok)
{
Status = DUET_STATUS::ERROR;
Serial.println("Error");
Serial.print(error.c_str());
Serial.println(error.f_str());
return; //There was an error deserializing the json
}
const char *status = doc["status"];
switch (status[0])
{
case 'I':
Status = DUET_STATUS::IDLE;
break;
case 'P':
Status = DUET_STATUS::PRINTING;
break;
case 'M':
Status = DUET_STATUS::SIMULATING;
break;
case 'B':
Status = DUET_STATUS::BUSY;
break;
default:
Status = DUET_STATUS::ERROR;
break;
}
Progress = doc["fraction_printed"];
//Hotend Temp1
hotendTemp = doc["heaters"][1];
fanSpeed = doc["fanPercent"][0];
The hotendTemp and fanspeed look like they are getting 'extracted' from doc and assigned to variables. But when i print those, they are still just zero, or whatever they were initially assigned.
I've been trying with the first neopixel code to get some response from the duet but it doesn't seem to send anything back at all. I've confirmed the TX is still working as i connected up a panel due and it worked just fine.
This is clearly well out of my skill level but i think ardunio to duet is still the best way to do this.
@sindarius I've read through all your code and I think I can modify that to do exactly what I need. One question, did you need anything in the duet configuration to get this to work, or does it automatically respond on serial?
@oliof That only raises the question, how do I then connect the the USB port to the arudino?
@pcr already got a good bunch of stuff working on the arduino which i'd rather keep. I'll keep that in mind though If I can't get it working, thanks.
@sindarius I think that will help. There is a lot of code there. It looks like main.cpp is the main bit that I need to look at. How often were you able to grab data from the Duet and how long does response take, any idea?