Topics created by Ak Eric

@ak-eric VPN is one of those non-trivial things that is going to take some doing to setup unfortunately. I haven't found a simple tutorial to follow. There's going to be several ways to approach it. I would suggest doing a search for your particular router and going from there.

I view the webcam stream as something less sensitive than actual printer control to expose to the internet so I'm ok with forwarding the port and accessing it directly. You might feel differently about the contents of your build plate though.

So, the 'view over two browsers' happened again. Unfortunately I wrote the gcode down wrong you told me to enter... I wrote M112 (emergency stop)... which isn't at all what I should have typed in. So, after that I tried the M122, but it had nothing to report.
Also note, that I'd been logging in from multiple browsers (on my PC and phone) pretty constantly for the past half hour testing stuff and this didn't happen. Then, it did.

However, the initial bug was, I logged into the DWC from my PC (had been logged in on my phone), it asked for my password (which was weird, since I had just been using it a few minutes earlier, then closed chrome), and after entering it (possibly wrong), the whole machine reset and quit. Luckily I was only 10 minutes into a print this time.

I'll continue to try and repro this and enter the right gcode next time...

@ak-eric said in Suggestion to add to where the 'Webcam Surveillance' is located:

However, this would have to be repeated any time I did a DWC update, right?

Correct. Hopefully, Christian Hammacher will include it. Seems easy enough. If not, yep, you'd have to tweak it after every update.

S3D Support got back with me. Looks like they hardcode that initial retraction 😵

But they did provide a solution that I'll give a shot:

"Although it is not possible to remove the initial retraction, we do have a suggestion to help you move forward. We noticed that all the retractions that are of interest to you are preceded by the tool-change command T0. Therefore, in your post-processing script you could consider including this as a condition with an IF statement or use the TOOLREPLACE as mentioned in this forum post. Then you could delete the remaining retraction prior to the tool-change using the DELETE command."

@Ak:

After some testing: But it's strangly cute watching the tooldhead bop up and down 1mm as it cruises off somewhere else in the print. .

I typically use .2mm which is plenty in my opinion

FWIW, I do not have 'wipe with retract' on the machine used for this test: I've found if I'm using a volcano nozzle from .8-1.2, this has a large advantage in reducing blobbing from all the drool that falls out. But on .4-.6mm nozzles, not so much, and in fact, can actually make the print quality look worse in some cases, IMO.

But you bring up a good point: I've actually wondered (and not yet tested, although it would be easy) the same thing: If, in S3D, you have 'wipe with retract' set, but also enabled firmware retraction (via scripting solution of m101/m103) what would happen? Can you combine the two? I thought not, figuring S3D would be doing some sort of magic wipe/retract combo gcode, while firmware retraction (I presumed) 'just retracted', and had no concept of combining that with any other move at the time.

Did I forget to mention the new firmware precognition feature? 😉

An alert from a filament monitor will also cause a pause.

When I first built the machine, I tried to get the same 'feel' from the wheels when sliding them in the extrusion: I'd tighten one two what felt 'correct', then would do the other, flipping the carriage upside down so they could be inserted the same and tested. However, quite possible I got that wrong on some of them… seems more art than science. Feel like that design could use an update: 2 wheels on one side, with a single, in the middle on the other side, that is eccentric. My core-xy bot has a number of sliders setup that way.

Just looking for this feature as well.
A lovely graph or other graphic display will always be nice, however…
initially I would be happy to have Machine Status -> Extruder Drives show mm/sec over last 3 (? maybe configurable 1-5 in settings) seconds.
Obviously this will dissatisfy those who get value out of seeing the mm extruded here, so maybe having a toggle on the display would be nice .. and then people will want toggles to show mm/sec for each of X, Y, Z and E[n].
So this would be same update rate as currently shown, just some adds and a divide to calculate the display value.

I guess I didn't realized I'd changed it from default? In my head, you always have a hotend cooler, so making it fan0 would make sense there. Not all printers have a filament cooler, or possibly more than one, so having them be 1+ seemed logical.

But good to know the standard, not hard to switch back around. Thanks

One cause of vertical lines in a print is DRV8825 and similar drivers failing to implement low-current microstepping. Changing the layer height so that it is not an exact number of full steps causes the problem to occur at different positions in each layer, so the positions do not line up and the lines are much less visible.

The symptom being described at the top of this thread appears to be different, although if the layer height for these prints is not an exact number of full steps then it could be related.

My guess is that it's extrusion-related. If so, then if the print is repeated with a different extrusion width, then the spacing of the lines will change in proportion.

Yes, that setting in S3D would cause that problem, so disable it.

AH, that makes a lot more sense, thanks for info.

Updating to 1.19.2 + adding that extra code fixed it, so thanks for that! Pauses/resumes like one would expect now. Plus I can confirm 1.19.2 works fine on RADDS (thus far). The only change I need was to my Y-stepper direction, per the notes for CoreXY machines.

But more exciting for me, is that this was the first firmware update that allowed me to do it via M997 S0 : Up until now, that simply "didn't work" for my RADDS board, and I had to use the 'manual technique of using a half-broken Popsicle stick to hit the internal reset button on the Due', which also involved an annoying process inf digging the board & its wires out of it's case. Anyway, that's a thing of the past now, really made my day 😉

On delta and SCARA printers, the only moves allowed before homing are G1 S1 moves (homing moves) and G1 S2 moves (special moves). I have it in mind to extend this restriction to other printer geometries in the next firmware version.

To follow up from another post: In fact bed.g with G30's in it, or config.g with M557's behave the exact same: I had a bug where I was crazy under-extruding, that I fixed at the same time I switched from bed.g to the M557 test. Switching back to bed.g with the correct extrusion steps now has the exact same behavior as the M557's in config.g. I like the separate bed.g macro, so I think I'll stick with that. But thanks for the help troubleshooting!