rtyr
commented
3 years ago Thanks.
@pmjdebruijn Would you please look into it?
Closed AstroSmoke closed 3 years ago
rtyr
commented
3 years ago Thanks.
@pmjdebruijn Would you please look into it?
rtyr
commented
3 years ago I believe @tylers tested current profile on his CR-6SE, so it is weird. https://github.com/prusa3d/PrusaSlicer/pull/5961#issuecomment-777548774.
pmjdebruijn
commented
3 years ago @AstroSmoke Oh, I just noticed you're already on the latest firmware... :(
WRT the X2.3, this is where the primeline is placed, we want this close to the edge as the primeline essentially shrinks the usable bed surface by a tiny amount. So this is well considered.
pmjdebruijn
commented
3 years ago Though it's unlikely that the start_gcode has a "fault", moving to X0/Y0 should never cause an issue after G28, so the issue is likely with the printer or firmware, especially given that another user has already reported good results.
However, let's try to get a better understanding what's really going on...
If you turn your CR6SE on ... ... then autohome from the menu, then via the menu slowly move to X0, does this result in ramming or not? ... then start autobed levelling from the menu, then via the menu slowly menu to X0 again, does this result in ramming?
In both cases above, you can move per 1mm, if you can't reach X0, it would be interesting to see at what X coordinate ramming is imminent...
Also, if you remove the G29 from the start_gcode, does the ramming suddenly disappear?
AstroSmoke
commented
3 years ago (this is a repeat note on the main forums) I can't find the link reference at the moment, so i could be wrong with this comment, but I think the person who submitted the setup Gcode for the PrusaSlicer did so with the aftermarket mother board or aftermarket firmware(not sure which). Alas there is currently 3 versions of the genuine motherboard for the CR-6SE printer where with the two 32bit variants you have different firmware for the same revision number. Without diving into the firmware and chip sets there could be an underline built in undocumented (bug, flaw, limitation, insert preference) between the 32bit boards and most likely the aftermarket firmware.
This maybe is why Creality played safe with the start Gcode and did not add the auto levelling as it causes a loss of location memory? (Speculation)
I had a quick glance at the marlin wiki and G28, G29 commands and there is an odd comment with G28 with reference to the G29 or levelling commands. So the problem may not with be Creality boards/firmware, but built into marlin. The quote taken from marlin G28 where the note references some interplay between autoleveling and homing.
Homing is required before
G29
,
M48
, and some other procedures.
If homing is needed the LCD will blink the X Y Z indicators.
G28
disables bed leveling. Follow with
M420 S
to turn leveling on, or use
RESTORE_LEVELING_AFTER_G28
to automatically keep leveling on after
G28
.The note is arguably lacking in whats going on between the two commands . But it reads that homing interferes with autolevelling somehow, maybe this is just an interrupt and does not damage the location data, however in my case this is what happens, zero or home appears to be lost when G29 follows G28.
In the end a coverall maybe just run "G28" "G29" "G28" to reset the home location, then for safety sake run the warmup strips at X10 and go there slower rather than try to drive the X axis through the wall.
However, an instant fix right now is to do the Creality suggested startup Gcode with a side note/warning in the startup code area, adding the G29 auto levelling requires careful testing for each user because of undocumented differences in boards and firmware.
I'm going to do a test, but it will be in a couple of weeks after I get work backlog cleared.
regards
rtyr
commented
3 years ago Does it work OK if you just remove the G29 command from the current start g-code?
AstroSmoke
commented
3 years ago @rtyr Don't know, haven't been brave enough to run PrusaSlicer again yet, not until I get a collection of responses to my problem. I have had to revert to Crealities Slicer to get work done, the printer has been purchased for a sensor I've been developing for a university project, so it is working pumping out parts to find the limits I can and can't do.
I might do that, remove G29, and or additionally move X to the center, infact thinking about that I might do the strips as a cross at center and see where the printer thinks it is.
@pmjdebruijn I'll do your test, the only issue I see at present is that you can't see where you are XYZ on the board numerical, or I haven't found the page that displays it. That would instantly tell me if zero/home is lost. I've got a Pi setup with Octopi, just waiting for my ITS dept to deploy me an IP address to hook it up, as the printer is in my workspace at University. So hopefully octopi can display location data in real time.
FWIW I like the workflow of the PrusaSlicer, it actually works layout wise for me and the compartmented structure is easier, I'm struggling with CURA/and the creality version as I find myself always searching for and missing settings. I would of got a Prusa, but had a budget constraint, however already I'm having payoff and can see a Prusa model being added in the not to distant future.
Additional information, work flow. I use Autodesk, Autocad then output the models with _3DPRINT as stl file (This is Autocad not Fusion 360)
pmjdebruijn
commented
3 years ago @AstroSmoke further speculation really isn't helpful...
What would be helpful, if you would issue a M503 via serial, and paste the output here. I have a suspicion you have misconfigured Workspace Offsets.
Did you test any prints from SD Card? As octopi may be a contributing factor...
rtyr
commented
3 years ago I checked Cura and Creality Slicer (Cura) and G29 command is not used there. It is possible, that some custom MBL is automatically initiated by G28 (we are doing the same thing on MK3).
pmjdebruijn
commented
3 years ago @rtyr: I'll file a pull request soon...
Though @AstroSmoke I'd still like to find out what's exactly going on...
rtyr
commented
3 years ago Updated configuration bundle (0.0.16) is live. @AstroSmoke can you please update the settings (you have to start the PrusaSlicer at least twice) and try to print something?
AstroSmoke
commented
3 years ago @pmjdebruijn Please note I do not have Octopi attached yet, awaiting assigned IP address from my network administrators.
@rtyr A little confused, download the software again but the same, then realised I need to run check for updates. ran the check for updates on the configuration tab. rebooted, loaded different Gcode config
Ran some tests. Found the X and Y position numerical positions show on the "Ready/move Axis" display.
Noticed Stop positions indicated X-5 Y-2
ran Zero Location data X117 Y117 manual measured the plate from left and front, minor deck positioning error, could be corrected in X by moving plate slightly. X119, Y115
Ran zero from levelling screen X117 Y117
Ran ABL, upon completion X117 Y117 Double checked with manual measurements from front and left X119(glass plate edge distance to nozzle) Y122(glass plate edge distance to nozzle)
Moved nozzle with manual adjustments 10mm then 1mm steps to X0 X was inside 3mm from plate edge Moved nozzle with manual adjustments 10mm then 1mm steps to Y0 Y was inside 5mm from plate edge, I note very close to hitting the mounting clamp
Made up a small test model with 10mm holes sliced it with the updated 2.3.1
I performed auto levelling manually from screen and zeroed
ran prusaSliced model no crash at start routine,
Strange movement though. The nozzle lifted to Z50 along the path, even though Z is set after the warmup to Z0.28
order happened as follows,
nozzle moved to X2 Y10 correctly with a Z height of 50
waited for warming sequences
Z dropped to Z0.28 and tried to extrude along Y to Y10
But as it moved the Z raised to Z50 again
This is curious, Running a crealitySlicer or CURA 4.8 which run the suggested start Gcode follow the nozzle priming sequence without error. One main difference I notice with the Gcode is crealities suggested code are explicit for XY and Z on each line The arrangement in PrusaSlicer takes the assumption the last position command is kept, arguably there is no reason to think that this is not as correct as full XYZ and E for each line.
But it appears that the Z axis returned to the previous Z position, Z0.28 back to Z50 even though the Gcode states Z50 then Z0.28
Again i'm not see this in Crealities slicer or CURA, but maybe the 4.5.2 board firmware has some oddity to look for a Z position if none applied and selects a prior one.
This might explain the crash, if you don't apply full XYZand E for each line it pulls information from earlier.
BTW the part failed due to coming loose from bed(PETG), I should of added brim, might rerun with some PLA.
G90 ; use absolute coordinates
M83 ; extruder relative mode
M104 S120 ; set temporary nozzle temp to prevent oozing during homing and auto bed leveling
M140 S[first_layer_bed_temperature] ; set final bed temp
G4 S10 ; allow partial nozzle warmup
G28 ; home all axis
G1 Z50 F240
G1 X2 Y10 F3000
M104 S[first_layer_temperature] ; set final nozzle temp
M190 S[first_layer_bed_temperature] ; wait for bed temp to stabilize
M109 S[first_layer_temperature] ; wait for nozzle temp to stabilize
G1 Z0.28 F240
G92 E0
G1 Y140 E10 F1500 ; prime the nozzle
G1 X2.3 F5000
G92 E0
G1 Y10 E10 F1200 ; prime the nozzle
G92 E0
Additional information. I just loaded CURA4.9, resetting all past settings from 4.8
I found additional parameters I can't find in PrusaSlicer 2.3.1 Prusa only displays the bed size X235Y235 and origin at X-5 Y0 As I found earlier, Y should be Y-2 a minor difference
I cant find printhead references as Cura displays, although Cura doesn't show Origin.....sigh
CURA4.9: Printer Bed X235 Y235 Z250 Rectangle Heated Bed Marlin
PrintHead: x-26 Y-32 Xmax 32 Ymax 34 Gantry Height 25
AstroSmoke
commented
3 years ago Another thing I am puzzled by as there is little or no documentation upon ABL from Creality, however looking at Marlin documentation for Gcode G28 https://marlinfw.org/docs/gcode/G028.html
According to this document ABL is disabled once a G28 is run and requires a "M420 S1" to reactivate ABL https://marlinfw.org/docs/gcode/M420.html Another thing I noted about G29 is that if no home defined as G28, the G29 performs a home routine first. I read the info then lost the reference for that douh! But I view that behavior of check stops (home) when I run ABL from the display.
So I am puzzled, if I manually run a ABL from the menu then run a print, does the Home G28 disables the ABL?? Or Is there a built in reset M420 S1 in the firmware to read the Z mesh regardless?
And of course Marlin explicitly states to run G29 (ABL) after the G28
I might add the G29 into the CURA4.9 start code, slow the feed rate to a crawl and watch what happens. Right now a CURA or Creality sliced part runs without problems, obviously without the G29
AstroSmoke
commented
3 years ago I ran a bed levelling test. I needed to prove or disprove that G28 disables autobed leveling as the Marlin documentation describes.
I installed a fresh copy of CURA 4.9, additionally i installed the profiles of printer tests. I sliced the bed levelling test that places nine pads across the bed and loaded it on the SD card.
I ran a manual auto bed levelling, but running the ABL from the user display. Except for the first home sequence, then whilst the bed levelling sequence was running I slipped a 3mm thick piece of plastic under the nozzle so that the level would adjust 3mm higher than the home position.
Then I ran the ABL test. The nozzle floated 3mm above the bed, along the initial flow along the edge then as the ABL test pads.
The conclusion is G28 does not disable the G29 command as Marlin describes.
However maybe their intention is that G28 interrupts the G29 command should a "G28" be activated during the G29 sequence.
I tried to test this, unfortunately you cannot exit the ABL screen whilst the sequence is running to stop the sequence, this is a FAIL in itself as any automatic processing device or mechanism should always have a safety stop button.
Another ABL test I added G29 to the CURA4.9 Start Code, and slowed the feed rates down to F100 and re-sliced ran the previous ADLtest. The printer ran the first home, then the ABL, but then tried to run off the front edge of the surface area.
So this proves that for some CR-6SE's you CANNOT include G29 ABL into the start code. the slicer software is irrelevant as it is an issue with the Creality C-6SE firmware revision/board revision.
Returning to the start code, I still stand by that for all generic users of CR-6SE's and the variants that the start code MUST adhere to the advisory document provided by Creality with their CR-6SE printers. Specifically the start code needs the full XYZ+ F and E parameters for each line, as the advisory document prescribes.
This is what CURA4.x uses and I have no problems myself, except for the built in design features(insert flaws) in the firmware and hardware. If I was to continue to try and test using prusaslicer 2.3.x I'd have to remove your default start Gcode and replace with the creality default. However there is other semi hidden settings CURA displays for the print head. (Or I can't find them in your setup) These other settings arguably don't change, but they need to be seen, especially when fault finding.
Hopefully these tests aid in the prusaslicer printer setup for this specific printer.
AstroSmoke
commented
3 years ago Ok my curiosity got the better of me.
I added a G29, with a G28 M20 S1 after and the ABL test pattern.
This is the start code, and this worked. note this contains two slow feed rates to allow emergency stop after the G29. So these need reverting. However there was one odd movement, between the G29 and G28, it was like a jam halt then G28 home activated. The other observations is it would need nozzle temp tuning, just lower than melt temp so that ABL doesn't place drops at each point.
M201 X500.00 Y500.00 Z100.00 E5000.00 ;Setup machine max acceleration
M203 X500.00 Y500.00 Z10.00 E50.00 ;Setup machine max feedrate
M204 P500.00 R1000.00 T500.00 ;Setup Print/Retract/Travel acceleration
M205 X8.00 Y8.00 Z0.40 E5.00 ;Setup Jerk
M220 S100 ;Reset Feedrate
M221 S100 ;Reset Flowrate
G28 ;Home
G29 ;ABLtest
G28 M420 S1
G92 E0 ;Reset Extruder
G1 Z2.0 F200 ;Move Z Axis up
G1 X10.1 Y20 Z0.28 F100.0 ;Move to start position
G1 X10.1 Y200.0 Z0.28 F1500.0 E15 ;Draw the first line
G1 X10.4 Y200.0 Z0.28 F5000.0 ;Move to side a little
G1 X10.4 Y20 Z0.28 F1500.0 E30 ;Draw the second line
G92 E0 ;Reset Extruder
G1 Z2.0 F3000 ;Move Z Axis up
@AstroSmoke: Please paste the output of a M503 (via serial) here.
AstroSmoke
commented
3 years ago I can't get a USB connection, it shows up as something there but no driver will work(supplied on SD card).
AstroSmoke
commented
3 years ago Seems my board USB has died, got a new board coming.
btw users of CR-6SE watch this video, important voltage problem fix, this is probable reason USB get blown https://www.youtube.com/watch?v=Wme0JIgXV2g
Of course stray voltage may induce other gremlins.
rtyr
commented
3 years ago I would like someone else to test current start g-code.
Here is simple test g-code (10min print, PLA): CR6SE_test.zip
I am interested in the behavior mentioned by AstroSmoke (bold text):
order happened as follows, nozzle moved to X2 Y10 correctly with a Z height of 50 waited for warming sequences Z dropped to Z0.28 and tried to extrude along Y to Y10 But as it moved the Z raised to Z50 again
The g-code is OK, so if it really happens then it is a problem on the printer/fw side. But still, we need to know if it is normal CR-6 SE behavior.
AstroSmoke
commented
3 years ago When in discussions with the CR-6SE I have here with the supplier on online chat, they did a parallel direct online chat with creality as well. I tried to establish when this printer was made, it has the 32bit 4.5.2 board, and had some build issues with fitting, loose bolts all around and poor clamping with missing nuts on the z screws mounts which made me suspect it was one of the later kick starter printers. even though I purchased the printer just a month ago. Then today I found the dud USB, anyway the supplier is sending from Creality a 4.5.3 board plus some bits. I did find floating voltage (5-6volts fluctuating) upon the usb shield to ground as per the prior youtube link I posted( those with CR-6SE please do the stray voltage test contained in that video, it may save your board, or PC/raspberry pi from destruction). I was actually testing with an USB Optoisolator which might of saved the PC usb port from an untimely end.
The stray voltage is kind of weird, by the earthing in the video it appears to be inductive in nature. Maybe poor quality wire insulation breaking down under higher current loads or they built in an earth loop. Or I have a dud board, which still prints but exhibits oddities compared to other users. No matter how it is generated this can cause erratic behavior with electronics.
As far as odd positioning behavior, my suspicion is that the 32bit 4.5.2 boards may be more likely to exhibit sensitivity to short cut XYZ code in the start Gcode and specifically the addition of G29 (ABL). Because of the rapid development I do wonder if Creality made minor hardware changes in the 4.5.2 board and did not alter the revision number. I do advise running the voltage test and the test (above) whilst observing movements, keeping your finger poised on the stop.
rtyr
commented
3 years ago G29 is no longer included in the start gcode
tylers
commented
3 years ago I received a notification about this a week ago but I’ve had some bad luck hardware wise. One of my steppers on the CR-6 died a few weeks ago and now I’m chasing down components since my motherboard seems toasted on my main pc. (Unrelated, I’ve always been afraid of the USB issue even though I’ve swapped out the glass bed/clips which should prevent the issue.)
I was hoping to be able to chime in with some additional testing but I’m not going to be able to test anything in the near future.
But AstroSmoke has done a stellar job of throughly documenting the behaviors. So I only have a couple things to add:
AstroSmoke
commented
3 years ago @tylers
I only started looking at 3D printers 2 months ago, I've sort of played rapid catch up with where 3D printers are at where my unfortunate budget was under $1000nzd. Unfortunately in NZ Prusas are $2000nzd for the kit i3. This left me with Printers such as the Ender 3 or CR-6SE, basically the feature set (ABL and double Z drive specifically) and cost of the CR-6SE was within the budget I was allowed (the Prusa mini isn't currently available here) but with that I noted that moans and groans (reviewers aside) of users subsided with the 4.5.3 revision motherboard. Therefore I tried to purchase the latest revision to avoid moaning and groaning on the world wide web. Alas I received the 32bit 4.5.2 board, as this unit appears to be a slightly improved version between the kick-starter and December 2020. Hence my moaning and groaning on the web :( (sorry prusa!)
The CR-6SE, is better described as three distant variants based upon the three versions of minor hardware changes but mostly motherboard revisions, irrespective of firmware changes. Frankly firmware changes generally can't fix flawed or faulty electronic design and manufacture. The fact is the two earlier versions of mother exhibit odd behavior, burn outs and stuff, then some with the same boards have no real problems. Except the stray voltage problem is common, (insert) burned usb ports.
The leads me to quality assurance as the main culprit and possible design flaws with the first two board revisions being the source of my problems with the prusaSlicer version of Start Gcode (with or without the G29 line). I believe at some level Creality identified some issues, hence the Start code document that comes with the printer(with this device) and is exactly as the CURA and Creality slicers currently use. If I use the Creality Start code my printer runs past the start code sequence as programed (I'd note after I fixed up all the mechanical build issues). I can't use the usb for Octoprint since the usb is shot.
When you have circuits with poor earthing, stray voltages, poor handling of electrical noise from steppers the chips and code do weird things. Then the problem for end users and software creators, is you chase symptoms not the cause. The only way to nail the cause is to isolate variables, so with something like this you have two choices, work around the issue, or replace the main likely cause. I believe Creality made a work around with start code and replaced the main source problem, the mother board 4.5.3 and they may be working on other earthing problems, that I do not know.
Because I found the stray voltage and blown usb with this unit, the supplier had two choices, replace the motherboard or money back/returned goods. Despite the printer actually printing I am not accepting of a partly working device, who would. But somehow I think Creality are replacing parts for those who report faults and not doing a replacement recall thing because in their eyes the affected is probably low percentage of the production.
Although because I used to design and produce sheetmetal parts using CNC punch and folding presses for electronics a few years back I did indeed open up all the cases and check build quality and to check wiring for faults. Sigh, a few flaws with the cable routing with wires being pinched by the case which then gets hot and slowly cuts the wiring. And, OMG that screw that pulls into thin air and that stupid screw on the top face! face palm!
Users of CR-6SE's please check your cabling into the motherboard case is not being pinched by the cover, this will cause a short circuit eventually. A sign is a pinch mark on any the cables entering the case. There is actually a zip tie point not being used, use it to pull the wiring over away from the pinch point. You know if you have clearance if the case cover fits home against the screw points without squishing the wiring. I'm considering cutting the opening for the wiring a little larger and adding wire protection rubber boot and or heat shrink.
But where does this leave PrusaSlicer and the CR-6SE?
Unfortunately by being more open to other manufactures for which you have zero control one is forced to be more conservative, however the marketing of using the competitions software allows the manufacture to offer their head space to the end user with alternative products. I must say I do prefer the PrusaSlicer ergonomics over CURA and Creality Slicer CURA, I just can't use PrusaSlicer at the moment until I get an updated motherboard. More of a trust issue, even if I use the default Creality Start code.
However I will point out again, in the released version of PrusaSlicer 2.3.1 the Start code of the CR-6SE is not as Creality recommends.
Because I found an issue with this particular printer which may indeed have a one off fault cause case is largely irrelevant, Creality made the move to include a printed document of the Start code for a reason, whether this is to get around a design problem or firmware problem or both is also irrelevant. They identified the start code provided as documentation as the best practice for this device as a whole production line, not a one off user case. Just because they may have made a bit of a woops with development doesn't mean they don't know what they are doing. I'm sure Prusa development has had their off days too!
Alternatives to the start code recommendation should be treated with caution, careful testing before use.
If I was running PrusaSlicer development I'd enforce best practice for alternative brand products specifically if documents are provided, case in point being that the fallout of other random users who have a similar crash as me will point to the software brand name not the hardware and they may not be inclined to moan as me on this forum but never touch neither manufactures product again. Many never voice their opinions or concerns, they voice their opinions where they spend their money next.
gosh that tuned into a rant! , hopefully I got the two main points across.
pmjdebruijn
commented
3 years ago @AstroSmoke: please don't rant in here, it just gets in the way of getting to the bottom of your issue.
We don't use Creality's start_gcode because I want to provide a consistent experience between all Creality printers we support. Aside from the current start_gcode and end_gcode arguably having better behavior. Copying vendor supplied start_gcodes verbatim would turn into an inconsistent mess rather quickly.
And more importantly, the CR6-SE thus far is the only printer that seems to have "issues". And we still have no clue, if the issues you are having are general CR6-SE firmware bugs, or just you having a broken mainboard.
From both @tylers and @AstroSmoke, at your earliest convenience, I'd like to see the (verbatim) output of an M503 command (via serial). And succinctly whether the current start_gcode displays any 'ramming' and/or z-lift during the prime line.
AstroSmoke
commented
3 years ago I guess I am having a consistent experience then. I'm pretty confident my experience will change to the preferred experience if and when I install a replacement 4.5.3 motherboard along with the insulation modifications.
In the mean time for the sake of others, my own curiosity and possibly if I never receive a new motherboard I will continue with my evaluations to try and establish root cause of the issues with the 4.5.2 mother board.
Since the serial over USB isn't currently an option to output M503, I see another possibility in the Marlin documentation.
Is it possible to output M503 data to the SD card.
I see M928 log.txt in the code list, and I wonder if I drop that into start_gcode followed by the M503 and then add the finish M29 into the end code. There is also the G800-M800 debug Gcode Parser, for deeper evaluation, although it is unclear if you insert M800 or G800 or either of them to start the debugger.
start_gcode removed example as this did not work
Anyone know how to run the log to the SD card?
AstroSmoke
commented
3 years ago @pmjdebruijn
managed to get M503 data
>>> M503
SENDING:M503
echo: G21 ; Units in mm (mm)
echo:Filament settings: Disabled
echo: M200 D1.75
echo: M200 D0
echo:Steps per unit:
echo: M92 X80.00 Y80.00 Z400.00 E93.00
echo:Maximum feedrates (units/s):
echo: M203 X500.00 Y500.00 Z10.00 E50.00
echo:Maximum Acceleration (units/s2):
echo: M201 X500.00 Y500.00 Z100.00 E5000.00
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo: M204 P500.00 R1000.00 T500.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
echo: M205 B20000.00 S0.00 T0.00 X8.00 Y8.00 Z0.40 E5.00
echo:Home offset:
echo: M206 X0.00 Y0.00 Z0.00
echo:Auto Bed Leveling:
echo: M420 S0 Z0.00
echo: G29 W I0 J0 Z0.15050
echo: G29 W I1 J0 Z0.11050
echo: G29 W I2 J0 Z0.08150
echo: G29 W I3 J0 Z0.11000
echo: G29 W I0 J1 Z0.09650
echo: G29 W I1 J1 Z0.05000
echo: G29 W I2 J1 Z-0.01050
echo: G29 W I3 J1 Z-0.01400
echo: G29 W I0 J2 Z-0.05750
echo: G29 W I1 J2 Z-0.10750
echo: G29 W I2 J2 Z-0.14200
echo: G29 W I3 J2 Z-0.15150
echo: G29 W I0 J3 Z-0.25000
echo: G29 W I1 J3 Z-0.26400
echo: G29 W I2 J3 Z-0.32750
echo: G29 W I3 J3 Z-0.28400
echo:PID settings:
echo: M301 P17.23 I1.24 D59.74
echo: M304 P79.49 I1.17 D1349.52
echo:Power-Loss Recovery:
echo: M413 S1
echo:Z-Probe Offset (mm):
echo: M851 X0.00 Y0.00 Z0.25@tylers @pmjdebruijn @rtyr
Further investigations. The floating voltages seem to float upon earth rails, and hence the shield of the USB, for some users they see 24v, I have 5~6v on the usb shield. As an experiment I added a further earth to the power supply building earth, attached it to the chassis upon the rail to the left of the USB. With an optical isolator between the USB and a laptop I managed to get the usb driver to load. Although it wasn't completely free of floating voltages this allowed me to get Pronterface to connect to the printer. This allowed me to get the M503 data.
I needed a small washer for a job I'm working on so I thought I can try to log from Pronterface the same part sliced on CURA4.9 verse prusaSlicer2.3.1 I was using the 2.3.1RC version and the 2.3.0 stable, but I was having trouble to auto update without a some files failing. So I uninstalled prusaSlicer 2.3.0, then downloaded a fresh copy of the stable release prusaSlicer2.3.1 and reinstalled.
sliced the washer in CURA4.9
washerCURA.zip
sliced the washer in prusaSlicer 2.3.1 washerTest_0.2mm_PETG_CR6SE_2m.zip
There are minor settings differences, as I have been using CURA and have low time using prusaSlicer. However mostly defaults with minor tweaks, 100% fill as I wanted the part solid.
Note at this point I have Pronterface still attached, and tried to run gcode from the SD tab. TESTRUN 1, prusaSliced version. Loaded Gcode; ok Bed and nozzle temps warmup; ok Home; ok z lifted 50mm; ok move X2Y10; ok beds and nozzle temps set; ok after heat up time
nozzle dropped down to run warm up runs. NOZZLE HIGH roughly 1~1.5mm Print ran through above the bed by 1~1.5mm
Print finished and presented, the blob. Nozzle temp failed to execute cool down and held at 240 degrees C
Manually set nozzle temp to zero
I cycled the printer power.
After reboot,
TESTRUN 2 I tested the CURA4.9 sliced washer from pronterface SD tab
Apart from the alternative sequence of events the CURA sliced washer printed as programmed. At the correct height 0.25mm Z for the base height offset. Bed and Nozzle temps went into normal cool down at the end of the print.
Curious.....
I cycled the printer power.
After reboot, I disconnected the USB, laptop, but kept the extra earthing to drain/ stabilize floating voltages.
TESTRUN 3, prusaSliced version from SD card, display executed
Loaded Gcode; ok Bed and nozzle temps warmup; ok Home; ok z lifted 50mm; ok move X2Y10; ok beds and nozzle temps set; ok after heat up time
nozzle dropped down to run warm up runs. nozzle correct height! Print finished and presented, the part.
Nozzle temp failed to execute cool down and held at 240 degrees C Manually set nozzle temp to zero
I cycled the printer power.
After reboot,
TESTRUN 4 I tested the CURA4.9 sliced washer from SD card, display executed
Apart from the alternative sequence of events the CURA sliced washer printed as programmed. Bed and Nozzle temps went into normal cool down at the end of the print.
Test run thoughts and observations
Obvious floating voltage, further insulation to be done, but replacement of 4.5.2MB with 4.5.3 MB which has upgrades targeting power regulation. Suspect most 4.5.2 boards to be ok, however a percentage of parts/boards got past manufacturing QC thus leading to the route cause of floating voltages and potential irregular behavior.
From my test runs the consistent pattern observed had errors with commands not being executed. Potentially there is two possible routes, firmware and hardware fault (floating voltages)
The differences between the slicers and relationship with errors observed. The pattern is single commands not being executed as intended.
A careful look at the gcode differences I see a couple of patterns in design, CURA does a few double executions of the same number, in the early section, G92 and where the prusa fails to turn off the nozzle with a single M104, CURA runs twice M104 S0 a few lines apart. CURA also sets Z height on most command lines with full XY E and Z, although occasionally it does a move up Z on its own. Really hard to spot this within a print run, would need a test run with repeats of movement to see it. PrusaSlicer tends to move the Z on a single line, although the printer did a complete print with the part more or less as intended, so the pattern is not an "always" case. It appears to be an "occasionally" fail to execute.
So far I have made a few models of my development program, sliced in CURA, and mostly I have no observed failures to execute code, maybe that is why they double execute is in CURA and the Creality version. I wonder if they do the double execution with the ender 3, 5 CR10 line up, or is specifically with the CR-6SE.
Examples of slicer Gcode comparison
prusaSlicer section of gcode as per
G1 E-5.00000 F3600.000
G1 Z0.200 F9000.000
;AFTER_LAYER_CHANGE
;0.2
G1 X112.438 Y112.438
G1 E5.00000 F2400.000
M204 S500
;TYPE:Skirt
;WIDTH:0.42
G1 F900
G1 X113.555 Y111.526 E0.04521
G1 X114.805 Y110.868 E0.04429Then CURA in the same section
G1 Z2.0 F3000 ;Move Z Axis up
G92 E0
G92 E0
G1 F1500 E-6.5
;LAYER_COUNT:10
;LAYER:0
M107
G0 F6000 X107.341 Y107.818 Z0.2
;TYPE:SKIRT
G1 F1500 E0
G1 F900 X108.195 Y106.989 E0.03959
G1 X108.362 Y106.843 E0.04696CURA at the end,
G0 F9000 X118.449 Y119.587
;TIME_ELAPSED:81.608852
G1 F1500 E17.35235
M140 S0
M107
G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positioning
G1 X0 Y235 ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
M82 ;absolute extrusion mode
M104 S0
;End of GcodeAnd prusa end of gcode
G1 X119.498 Y118.224 E-0.18036
G1 F7200.000;_WIPE
G1 X119.325 Y118.580 E-0.18789
G1 F7200.000;_WIPE
G1 X119.085 Y118.909 E-0.19361
;WIPE_END
G1 E-0.07500 F3600.000
M107
;TYPE:Custom
; Filament-specific end gcode
;END gcode for filament
G1 Z4 F600 ; Move print head up
G1 X5 Y188 F9000 ; present print
G1 Z72 F600 ; Move print head further up
G1 Z150 F600 ; Move print head further up
M140 S0 ; turn off heatbed
M104 S0 ; turn off temperature
M107 ; turn off fan
M84 X Y E ; disable motors
Thanks for the further testing...
But unless I've missed something, the gcode isn't really relevant to the problem. It's just a case of dangerously defective hardware. The only responsible course of action seems to be fixing the printer properly. Which is replacing the mainboard in all likelyhood.
On a sidenote, there are drop-in third party mainboards available for the CR6SE from SKR, and typically SKR boards tend to be superior to Creality's own, but I can't vouch for the CR6SE replacement specifically. One thing to keep in mind is that the touchscreen might complicate drop-in replacements, so do your own research thoroughly.
@rtyr, unless you disagree with my conclusion, I think you can close this issue as invalid.
AstroSmoke
commented
3 years ago @tylers @pmjdebruijn @rtyr
Yes I agree, commands should be executed not ignored or lost. This is the Creality board/system fault, however, Gcode is not entirely clear yet not a prusaSlicer fault but an observation of CURA. I had a quick look at CURA where I added an ender 3 profile and sliced a simple test model with the ender 3 profile then the CR-6SE profile.
Curiously I see double commands with both profiles, specifically to turn of nozzle and bed heaters. What this means is that Creality Printers may have a general method to cover printers which have problems executing commands so they add the command twice within a short period.
This could be a coverall on CURA's part to cover themselves with selected problematic Creality printers and a command twice to do the same thing as turning off heating is just insurance for those without problems.
So the question is, do other Creality printer users who use the prusaSlicer experience the nozzle or bed not turning off at the end of a print? Then for insurance, should prusaSlicer also add double commands for all creality printers to turn off heaters specifically?
Example CURA4.9 CR-6 Gcode, end of print section
G1 F1500 E1240.00818
M140 S0
M107
G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positioning
G1 X0 Y235 ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
M82 ;absolute extrusion mode
M104 S0
;End of GcodeExample CURA4.9 Ender 3 Gcode, end of print section
G1 F2700 E1135.00067
M140 S0
M107
G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positioning
G1 X0 Y235 ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
M82 ;absolute extrusion mode
M104 S0
;End of Gcode
Curiously I see double commands with both profiles, specifically to turn of nozzle and bed heaters. What this means is that Creality Printers may have a general method to cover printers which have problems executing commands so they add the command twice within a short period.
Cura always emits M104 S0/M140 S0 at the end, no matter if those commands are already used in custom end g-code section.
I am closing this issue, it is most likely HW issue.
AstroSmoke
commented
3 years ago @tylers @pmjdebruijn @rtyr
Just an update
Replacement 4.5.3 mother board plus insulation kit arrived, pity no instructions! sigh.
Installed the insulation kit and new mother board, mother board came with 2.0.1.3 firmware installed. Trick with light sensor for the load cell, sensor position inserts into port J2 on the 4.5.3, on the 4.5.2 mb the sensor is in J1 Also installed the 4.5.3 DWIN graphics board firmware as there appears to be different DWIN files between the two mother variants.
If you don't do the above updates, the zeroing home drives the z into the glass until the steppers miss steps. Not good,
Running the test washer from previous tests, PrusaSlicer2.3.1 and CURA4.9 Both perform well, apart from the different sequence of events between the two sliced programs, I observed NO errors and NO missed executions, such as bed and nozzle cool down.
This confirms the faults observed with operation, which prusaSlicer high lighted, was no fault of prusaSlicer, but a Creality hardware QC issue with the stray voltage and faulty 4.5.2 mother board.
regards
Please note I reported this bug in the Pruca forums, didn't see the report here at github until after I posted(Nigel) sorry about that.
Version
Version of PrusaSlicer 2.3.1RC
Operating system type + version
Win 10 64bit
3D printer brand / version + firmware version (if known)
Printer CR-6SE, 32bit 4.5.2 board Creality firmware 2.0.1.3
Behavior
Default CR-6SE profile. FAULT ERROR: After warmup then Automatic bed levelling, the Y axis lifts then then the X axis rams into Y axis post, stepper still drives. There is a nasty fault in the Gcode for the CR6SE in the "Start Gcode".
_Is this a new feature request?_NO, fault
Creality suggests this;
2.31RC has this ;
The fault I suspect is the addition of the auto bed leveling then driving the coords to X2 Y10. This was the crash.
I suspect that G29 loses the home position, maybe the command switches to relative positioning, who knows? I'd possibly fix this with another G28 after the G29, which is what I do with a manual "home" after auto bed levelling. However I do not like X2 dimension, why drive it so far over? Creality suggests X10.
Anywho, for Prucer developers, my suggestion here is to use the default "start code" creality suggests, I just checked and notice this is what CURA 4.8 uses. If someone wants to add the auto bed leveling they can do so themselves, where I'd note doing so appears to have an issue for coords on completion and might require another homing command to get around the issue.
regards