ArcWelder gives strange output (I use console app
):
P.S.
Never mind, cura and ideamaker fail to show this gcode.
While repetier shown it properly.
Look few posts down for analysis results
Yes, all settings are same or as close as possible.
Now I did several more tests - excluded supports, infill.
This run with infill but no support.
Without support Cura generates 10% less moves:
With supports added (same density and patterns, though it still looks differently) cura doubles extrusion moves.
Also in supports it does not respect its own setting for mesh mixes - max resolution (which set to 0.5mm).
Maybe that's the reason cura so overdoing supports
Arc Welder for the win!
1 Like
Not on slow 8bit boards, probably, because of a lot of math
I don't know, works pretty well on my EinsyRambo board, and pretty sure it's 8 Bit.
So try to test 1 million G0 X1 on the pandaPi board
time echo | python fast-stream.py -q million.gcode /dev/tnt0
getting much:
Incoming: echo:Unknown command: "GG0 X1"
Incoming:
Incoming:
Incoming: echo:Unknown command: "GG0 X1GG0 X1GG0 X1G0 X1"
Incoming:
Incoming:
Incoming:
Incoming:
Incoming:
Incoming: echo:Unknown command: "GG0 X1"
Incoming:
Incoming: echo:Unknown command: "GGG0 X1G0 X1"
Incoming:
Incoming: echo:Unknown command: "GG0 X1GG0 X1GG0 X1"
It looks like the board is choking something...
It looks like the command is getting messed up with additional G characters.
And this is useful to us in what way?
First, I believe you have hijacked a thread that has nothing to do with your problem. Please start a new thread.
Second, in that new thread there will be a template with instructions and links (in blue) that suggest the information and level of detail that we need in order to help you. Please provide as much as you can. The more you give us, the more we can help you.
did you read the thread ?
I only posted the results when sending the gcode via a software based connection
I’m getting sick of prints stopping at 95% almost like ransomware. Give us our $$$ or your last 5% won’t print.
How do I get serial out of the picture completely? Is Duet board the only option? I have accepted possibly it is an issue with Marlin FW I am using but others are using the same firmware.
I’m ready to make my setup stable and reliable and I suppose if it costs it costs but this USB to serial stuff is too much - it hasn’t been reliable for me and judging by the size of this thread i’m not the only one.
Edit: anyway that was a joke in a sort of sad/ironic way to monetize anything 3D printer related. I updated to Octopi 18 beta 64 bit and communications are flying in the terminal now. Rock solid printing so far. So confident i’m running a 12.5 hour print now after testing some shorter ones. So glad I can keep the stock board and the L-shape usb plug cable I picked.
I never had this problem on 10 different instances of smoothieware on original smoothieboard, nor on 2 instances of smoothiware on teartime modded cpu to run smoothieware. I did have this problem with SKR/MKS boards running smoothieware and marlin2 (supposedly usb traces are not properly routed on mks/skr boards that's where the issues come from, lot of ppl talked how there is a reason smoothieboard is 4 layes and that while you can route everything in 2 layers you cannot solve all the noise issues and this type of problems are expected) ...
so solutions are
- use a proper 32bit board like smoothieboard with proper firmware like smoothieware
- print from SD card
I’ll bet there is something up. I am starting to believe the ferrite core people. This happened again just now. What did I do? I used my router with brushed motor to clean up some parts and connection time out. I bet it creates some nasty EMI.
Also other times it will work fine and just when I get home or a few minutes after it fails.
I think it’s due to auto switching of lights etc when I get home. It’s just very sensitive to something else on the circuit.
Smoothie ware sounds good but now version 2 is in the cards and I wouldn’t go for the older ones since they are really old at this point. So it’s going to be a wait if I go that way.
For the time being I’ll get some ferrites.
The thing I don’t understand is with all this software and tech how we can’t just easily restart a print. It knows where it left off at least to the layer level.
So I have restarted several prints at this point in the beginning of my 3D printing journey. Before I put in the BL touch it is was easy. I just put the gcode into notepad++ and edited out the homing commands and deleted all the lines for already printed layers.
After BL touch it got hard. The printer won’t print before homing Z. So I pulled out the plate replaced it with an identical (close enough) Creality glass plate let it home that - hit pause - change the plate with the model back.
Yes I got mild X axis shift but it finished.
There has to be a better way to recover from these situations at least.
A plug that just bypasses all homing or at least disables BL touch for one print and then resumes at layer x.
How I feel about it is that all this great tech and great software is let down greatly by the lack of that functionality. We prefer if everything works perfectly however that isn’t always going to be the case. So graceful pause and resume is a must have function. Whether the printer has lost power or needs to be cycled or even if it needs to be swapped - the 40 hour print with 2 hours lefts NEEDS to get finished.
These cheap printers have power resume if printing from SD. So Octoprint has to survive a printer power cycle or a printer crash. Taking that a step further is that it really could be logging its state every 500 or so lines and write to SD flash a file that will allow for resume in case it loses power itself.
Fine let’s argue that would kill the SD card. Firstly it should still be an option in that case.
Secondly let’s say the Pi CPU can’t handle it then we can at least put the Pi on a UPS so it can be preserved.
Recovery for software/FW/user errors is a must have function for a system like this.
almost all of the PRC boards (MKS, SKR and similar) have
- terrible power distribution design
- no EMI design at all
IMHO because they are based on open hardware boards (ramps, melzi..) that also have
- terrible power distribution
- no EMI design at all
this time mostly 'cause they are made by ppl who are not EE's but software engineers with basic understanding of electronics (as much as arduino movement brought good things it empowered ppl who should really not design boards for professional use to design boards that are then mass produced and are POS)
version 2 is "in the cards" for years and who knows if it will ever come out, v1 is awesome, board is awesome, firmware is awesome... it does not use the "best fancies tmc drivers" but it is a very good and stable system .. does not have all the bells and whistles but it is super stable and reliable ... I run all my cnc machines with smoothieware in grbl mode too ... wrt printers I'm slowly migrating to duet as I like the "on-line configuration change" duet offer and with new sbc link it will soon create env. for plugins similar to octoprint
they can't hurt,
- use good short high quality usb cable
- add ferite to usb cable on both ends
- loop the cable trough ferite beed at least once
- ideally cut the red wire in the usb cable
- make sure everything is connected to same outlet
- add ferite beed to the psu input too
this is a different topic all together, one that differs a lot on type of printer you have, type of control you have, processes you use ...
Thank you for your help. I’ll be installing the ferrites today.
As for duet it seems that currently Octoprint will not connect to it but only after SBC is added. I would prefer to wait and see.
Regarding resuming prints I have to figure out a way in firmware to disable BL Touch for just one print so it doesn’t need to hit the Z home first to print. There might be another way to set relative mode and have a program convert the Gcode to relative. I suppose it was wrong for me to just turn off the printer to see if it will reconnect. I wish Octoprint could just resume commands from there. Next time I will pause and go back and see the last coordinates the nozzle was at in terminal.
I do wish there were a way to save that data and keep it persistent even if the printer is switched off. However copy and paste from terminal also works.
I tried octoprint with duet and it works but it makes not much sense in using octoprint with it so I removed the octoprint from the duet printers. I already started porting the plugins that I use on octoprint to the stand-alone apps on the rpi that's only on the same network (not connected via usb) but my time is too expensive these days so that is on hold attm. even with duet3 + sbc or when duet2 + sbc enter "stable" release octoprint is not expected to be a player there unless someone does a serious rewrite / big plugin on the octoprint side, but the idea of duet+sbc is the whole new env duet ppl are making for writing plugins for that env ... it will offer similar features as octoprint does (hooks for different events, way to modify code etc etc) but it will be a more integrated solution compared to octoprint...
the main reason I started slowly migrating my printers from smoothieware (that I really like) to duet is the way configuration is done on duet. there is no "config", there's just a "power-on gcode script that's executed when board boots up", and another script that's executed in a loop and that's it. so you can change your config any time, any where... you can switch between bltouch and precise piezo in the middle of the print if you like, you can drop the current for your X motor before you start homing X so that, if something is wrong, it won't break anything but just stall and then after homing you return current to original value, or you can drop current on your extruder while loading filament so it will stop when filament reaches nozzle instead of grinding the filament etc etc etc ... so setting Z probe to bl-touch or induction sensor or switch or ... is matter of macro's you make and which macro you want to call
now, I don't have power issues as I'm running each printer on a small ups (in case I need to replug it, move it etc) and I run them all from a 3kVA ups with 72V 6000Ah batteries so some serious on-line time in case of power outtage.... so I did not try too many things wrt power outage, I know there are different solutions out there.. wanhao is some printers using their "screen" to send g-code and handle power failure scenario, creality is using from what I seen the same feature on the marlin directly ... killing of the SD card is rather common there.. prusa used to use a beefy capacitor on the main board to detect power outage so it would only store the current position when the power outage actually happens (marlin is storing it non stop, no clue what wanhao's touch screen does) .. IMHO solving power issue is better option than fixing "power off resume" in firmware. I'm moving to a new place soon (I hope) and I'll have to redo the workshop from scratch (finally). The idea there is to have a separate 24 or 36V rail for the printers as there's really no need for each printer to have AC->DC converter, fan, ups etc etc.. when this can all be handled directly from DC... small capacitor bank to handle glitches in case power goes out till a relay plugs in the standby accumulators directly on the line, no need for dcdc or dcac-ac-dc conversion and waste of energy...
duet have "registers" where the data is stored when you pause the print .. for e.g. my "pause.g" looks like this:
M83 ; relative extruder moves
G1 E-10 F3600 ; retract 10mm of filament
G91 ; relative positioning
G1 Z5 F360 ; lift Z by 5mm
G90 ; absolute positioning
; GO TO PARK
G0 X-135 Y65 F6000
and resume.g is something like this
M83 ; relative extruder moves
G1 E10 F3600 ; extrude 10mm of filament
G0 X-115 Y65 F3000
G1 R1 X0 Y0 Z5 F6000 ; go to 5mm above position of the last print move
G1 R1 X0 Y0 ; go back to the last print move
R1 is the interesting thing here
anyhow this is all unrelated to octoprint so..
If the same print job is dying at the same-ish point more than once...
- Is it because you're starting the job at the same time, time is passing and then around midnight something like... your refrigerator or the electrical heating system is kicking in, drawing lots of power and causing low-power situations for your Pi?
- Is it because something's going on with the gcode at this point in your print job?
- Is it because there is something different about the shape of the object being printed at this point (like the thin neck of some figurine)?
- Is it because of the amount of tiny circular paths made up of line segments which are too small for your 8-bit board?
- Is it because of electromagnetic interference from a large motor or fan being turned on?
- Is it from a brown-out in your power circuits you've plugged your printer into?
- Is it from a temperature change in the room?
I always use a good-quality UPS. I always have the bonafide power adapter for the Pi computer. I upgrade the power brick for my printer. I verify that my serial cable fits snugly at both ends, has internal metallic shielding and one or two ferrite cores. I try not to use inline serial adapters. I don't add USB-based LEDs/lights or anything that might drag the 5V line down on the Pi. I make sure that the Pi isn't back-powering the controller board over that USB line on the 5V pin. I try to add some foam to my printer so that its got an enclosed print volume.
more likely EMI then voltage drow / low-power
I had issues with SKR board for e.g. that would disconnect when heated bed engages, was working ok with old heater as that printer when left bed heater non stop on would settle around 105-110C that I use to print ABS so it was perfect, I increased power of the heater to get to set temp faster and it started disconnecting, partially solved by switching bed to PID from bang-bang switching... but still, my small (<100W) compressor turnes on, SKR lose the USB connection, I turn on fluo lights, USB is gone etc etc.. my main workhorse printer was for years modified TT printer, you disable motor drivers it lose usb connection... very repeatable .. it's all EMI, USB traces are not properly traced on the pcb 
and no protection.. it's a problem with many PRC boards, that's why not too many issues with 8bit boards as they copy the datasheed usb connection to the ftdi clone or th ch340 and then trace the rx/tx trought the board that's much slower and less affected by crappy routing