Closed inspectionsbybob closed 2 years ago
Version of Marlin Firmware Community build based on 2.0.8.x
Please download bugfix-2.0.x
to test with the latest code and let us know if you're still having this issue.
My idex machine last updated 2 weeks ago or so does not exhibit this. As this points to something not explicitly IDEX in general, please attach youre configuration files. G27 is nozzle park, and it sounds like the default park position was set to the E0 park position, not a safe place for either head to park during actions such as filament runout.
What is interesting is a T1 or T0 command parks correctly. It is the only the G27 that seems to have the problem. I will check with the developer and see what patch version he is working from... Please don't wait for me to respond when booking an inspection. I turn off my devices when on appointments and someone else could get your spot. Please CALL our service or book yourself online to save the spot as soon as you know the time you want.
Bob Sisson ACI, BVI Inspections by Bob ASHI Member # 212016 MD Home inspectors License #29666 MAC-ASHI Chapter President 2010-2012 ASHI Mid-Atlantic Group Leader 2009-2012 ASHI National Board Of Directors 2012-2015, 2017,2018-2020 @.*** www.inspectionsbybob.com (301) 208-8289 Scheduling/Pricing
On Thu, Apr 28, 2022 at 3:45 PM InsanityAutomation @.***> wrote:
My idex machine last updated 2 weeks ago or so does not exhibit this. As this points to something not explicitly IDEX in general, please attach youre configuration files. G27 is nozzle park, and it sounds like the default park position was set to the E0 park position, not a safe place for either head to park during actions such as filament runout.
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1112591825, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GY5M5CLUSBJ4OZNGW33VHLTFNANCNFSM5UTMFV6Q . You are receiving this because you authored the thread.Message ID: @.***>
@inspectionsbybob: Since you’re replying by email, your entire email signature is getting captured here on GitHub and is being mixed in with your reply.
Thats expected as they pull from totally different values. G27 relates to nozzle park, and will park the active tool in a safe location to pause. It should be accessible by both nozzles, and in idex duplication mode not cause conflict. Typically for IDEX this is recommended to be set to 1/3 bed size (eg 300mm bed, set to X100). I suspect NOZZLE_PARK_POINT has the first value at or near 0 and is causing youre issue.
I am not using duplication/Mirror mode. This is using the FULL BED in AutoPark for using PVA for supports.
I am aware of the use of Mirror and Duplicate. In duplicate, I can use Roughly 1/2 of the Full bed In Mirror I can use about 5/12 of the bed on each side with a 2/12 "no man's land" in the middle so the extruders don't crash in the middle. There are no T0 >> T1 >> T0 switchovers in those cases as they are both active for the entire print.
In this case, there are two switchovers per layer. It puts down the PLA, then switches to PVA to put in the supports, and then switches back to PLA for the next layer. Something Similar happens with multi-color prints with multiple colors per layer,
The actual material is immaterial, but it makes it easier to understand if you give the application.
On Thu, Apr 28, 2022 at 4:28 PM InsanityAutomation @.***> wrote:
Thats expected as they pull from totally different values. G27 relates to nozzle park, and will park the active tool in a safe location to pause. It should be accessible by both nozzles, and in idex duplication mode not cause conflict. Typically for IDEX this is recommended to be set to 1/3 bed size (eg 300mm bed, set to X100). I suspect NOZZLE_PARK_POINT has the first value at or near 0 and is causing youre issue.
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1112625299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GY5B24HYFNZU6LV7YJTVHLYHZANCNFSM5UTMFV6Q . You are receiving this because you were mentioned.Message ID: @.***>
Still need configuration files, especially the value currently listed in NOZZLE_PARK_POINT. Without that, we will need to point this back to whichever fork this is based off of as it sounds like a misconfiguration and not a bug.
I have seen this on my IDEX setup. To stop T1 crashing into T0 during pauses, I defined NOZZLE_PARK_Y_ONLY as a workaround. I have too many other issues to sort out first :-)
From my configuration.h:-
// Specify a park position as { X, Y, Z_raise }
//#define NOZZLE_PARK_X_ONLY // X move only is required to park
I suspect X_MIN_POS needs to be a lot larger to clear the left hand extruder/hotend. My X park position is about -70.
@scott-pett if you're X1 carriage is more than 10mm wide, I can see that... Try a position for X close to 1/3 bed size to allow parking during duplication too.
Sorry but your response makes no sense... X1 .... there is only X and as for being 10mm wide, most of us have 300x300x300 systems and some of us have a t1 and t2.
could you try again?
On Tue, May 17, 2022 at 2:08 PM InsanityAutomation @.***> wrote:
@scott-pett https://github.com/scott-pett if you're X1 carriage is more than 10mm wide, I can see that... Try a position for X close to 1/3 bed size to allow parking during duplication too.
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1129166765, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GYZMVXLK2MYCSUHXCHDVKPOBVANCNFSM5UTMFV6Q . You are receiving this because you were mentioned.Message ID: @.***>
--
Need a quick answer? Call our booking line at (301) 208-8289, or book your inspection on our website 24/7. Don't wait for a response as someone else may get the spot you want... call Today!
Bob Sisson, ACI, BVI Inspections by Bob, LLC www.inspectionsbybob.com @.*** MD Lic#29666; ASHI Member #212016
Sorry but your response makes no sense... X1 .... there is only X and as for being 10mm wide, most of us have 300x300x300 systems and some of us have a t1 and t2. could you try again?
Im talking about the size of print head, not the bed. If you set
Then you will park correctly with either tool, and when in duplication or mirror.
You are setting the park point into the middle of the left tool, regardless of which tool is active with the settings above.
Ah... in mirror or duplicate! There are quite a number of work arounds for Mirror and duplicate mode that can be (and have been successfully) put in the slicers that work in the "tool change" gcode options.
The biggest problem, which no-one has come up with a workaround for, is when in "Autopark" mode when trying to do either multi-color or soluble supports.
In mirror or duplicate mode there are no "tool changes" as it moves to print with both heads and then at the end it parks both heads, and those can be made to work.
In AutoPark mode however, there maybe a 2x tool changes PER LAYER. And the change from T1 to T0 is the problem. I saw some typos in the tool change code that I have called out, but there may be more that I haven't found yet.
The code for T0>>T1 is -very- different from the code for T1>>T0, which makes me suspect that section, even without the typos.
There are some additional issues with "nozzle cleaning/wiping" at inappropriate times, but those can be dealt with separately...
The T1>>T0 problem is a fatal error as it makes AutoPark totally unusable.
Mirror and duplicate can be made to work, but not AutoPark.
On Thu, May 19, 2022 at 9:10 AM InsanityAutomation @.***> wrote:
Sorry but your response makes no sense... X1 .... there is only X and as for being 10mm wide, most of us have 300x300x300 systems and some of us have a t1 and t2. could you try again?
Im talking about the size of print head, not the bed. If you set
define NOZZLE_PARK_POINT { (X_BED_SIZE / 3), (Y_MIN_POS - 10), 20 }
Then you will park correctly with either tool, and when in duplication or mirror.
You are setting the park point into the middle of the left tool, regardless of which tool is active with the settings above.
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1131669731, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GYYEBUUFAE4GCTRFSYTVKY4VLANCNFSM5UTMFV6Q . You are receiving this because you were mentioned.Message ID: @.***>
--
Need a quick answer? Call our booking line at (301) 208-8289, or book your inspection on our website 24/7. Don't wait for a response as someone else may get the spot you want... call Today!
Bob Sisson, ACI, BVI Inspections by Bob, LLC www.inspectionsbybob.com @.*** MD Lic#29666; ASHI Member #212016
Ill need to go back and look through it again, I havnt touched that code in some time now as it should have been stable at that point. Ive got a new idex machine I was working on getting code ported for I plan to finish this weekend and ill give it a shakedown. I dont recall seeing an autpark issue on the trex3 here a few months ago when I last brought it to head though.
Biggest issues ive seen with people getting into duplication or mirror mode is not following the correct command sequence. Eg for mirror mode - "M605S1\nT0\nG28\nM605S2\nG28X\nG1X0\nM605S3"
When I was TRYING to follow the code, I looked for "G28" and "Tool Change" and I found some weirdness. The following is a clip that I sent to the developer who is taking the Raw Marlin code and compiling it for OUR specific printer.
To my thinking the code for T0>>T1 and T1>>T0 should be mirrors of each other and behave the same... this just doesn't look right. T0>>T1 works fine, T1>> T0 doesn't and I couldn't find much more with my limited knowledge of how all the source files interect/are laid out.
The developer said I was on to something, said he found the rest of the related typos and then went on Holiday for a bit, and along with his day job has been unable to publish his fix yet.
Apr 28, 2022, 1:25 PM You sent I went looking in the source code and I don't understand something. The Configuration_ADV.H from marlin and your source are very very different, The command I was looking for was : //#define EVENT_GCODE_TOOLCHANGE_T0 "G28 A\nG1 A0" // Extra G-code to run while executing tool-change command T0 //#define EVENT_GCODE_TOOLCHANGE_T1 "G1 A10" // Extra G-code to run while executing tool-change command T1 The T0 and T1 commands are different, and I can't find anything similar in your code...
Sorry, one more comment. I tried lots of manual commands and found that G28, G27 and M125 all seemed to have similar problems, and I think they all call the same base routine (event?)
Again, I am used to straight line code with minimal "includes" so I had a really hard time trying to visualize the code flow and couldn't find the definitions for those other commands to see they did indeed all call the same questionable code/event.
I did a stare and compare with your code and our code and couldn't follow the links between modules, so I couldn't find where he included the questionable sections... but the developer did say that I had found something...
WAY beyond what is expected from Marlin volunteers, but here is a link to the Developers page that is integrating Marlin into our specific machine. Don't know if looking at his code would help at all. Again, WAY beyond the normal scope... https://github.com/TwinkieXLII/artistd/releases
EVENT_GCODE_TOOLCHANGE_T0 these are meant to be custom actions defined by the user, and can be quite literally anything you want. By default theyre off and just show something that you might want to do, like a nozzle wipe.
Looking at that source code, its exactly what I expected causing the crash on M600, M25, M125.....
Try changing it to
Hum... you had me until you said "in range of duplicate..." We have a work around for duplicate/mirror
It is AutoPark that we have a problem with.... On my system, T0 parks at -63 and T1 parks at 373 for a 310 wide bed. so it is for -63 for T0 and bedwidth+63 for T1... (endstops are at ~64)
Again, everyone seems fixated on duplication/mirroring and that is not where the fatal error is.
When I did some really basic tests such as the following from a terminal...
G28 ; home everyone to start clean T0 G1 xsomething ysomething ; works fine T1 ; this tool change works fine G1 xsomething ysomething ; works fine T0 ; << THIS tool change fails as T1 tries to park in T0's spot
I suspect that something lost track of which tool is active so it is still thinking it needs to put the active extruder to -63 rather than +373... (again my system values) If it still thinks T0 is active when in actuality it is T1 the behavior makes sense, wrong, but makes sense...
I did lots of testing from a terminal to try to figure out which primative was at fault, but couldn't get any deeper than figuring out G28/G27 and Msomething all behaved the same... they behaved as if the system thought T0 was still the active extruder. Every thing fine worked UNTIL it was time to park (T1).
PS... in my testing I noticed that the system behaved differently if the extruders weren't up to temp, as the Wipe commands were bypassed when cold... so I tested both hot and cold... same behavior less the wipes... so this eliminated the wipe event as the problem.
The ORIGINAL factory image that was based on Marlin 1.x didn't have this problem, but it had other issues...
On Fri, May 20, 2022 at 10:52 AM InsanityAutomation < @.***> wrote:
EVENT_GCODE_TOOLCHANGE_T0 these are meant to be custom actions defined by the user, and can be quite literally anything you want. By default theyre off and just show something that you might want to do, like a nozzle wipe.
Looking at that source code, its exactly what I expected causing the crash on M600, M25, M125.....
define NOZZLE_PARK_POINT { (X_MIN_POS + 3), (Y_MAX_POS - 3), 10 }
//TwinkieXLII try not to park in brush
Try changing it to
define NOZZLE_PARK_POINT { (100), (Y_MAX_POS - 3), 10 } // Dont
arbitrarily park toolheads in the middle of the T0 park point and instead go somewhere both heads will reach, still in range of duplication movement
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1133000715, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GY7S5EY3AJ7QS7OZDD3VK6RJVANCNFSM5UTMFV6Q . You are receiving this because you were mentioned.Message ID: @.***>
--
Need a quick answer? Call our booking line at (301) 208-8289, or book your inspection on our website 24/7. Don't wait for a response as someone else may get the spot you want... call Today!
Bob Sisson, ACI, BVI Inspections by Bob, LLC www.inspectionsbybob.com @.*** MD Lic#29666; ASHI Member #212016
In range of duplicate is to prevent a new issue from occuring if you go too far the opposite direction, eg if you set park point to X200 the right tool head will slam into it's endstop.
Issues on basic autopark though are new and not part of the original issue. I didn't see any last time I updated one of my idex's but something may have changed. I'll be working on a different machine this weekend and I'll put autopark through some paces while I'm there and see what I get.
I ran a bit on my config with dual material on autopark this weekend without issue. Ill need to go through yours and find differing options and match them one at a time to see where the problem comes in. For reference, here is the working branch I was using
https://github.com/InsanityAutomation/Marlin/tree/Tenlog_DWIN
Any luck or issues with your tenlog and dual color?
I have been going through the code in my spare time, found lots of questionable code where the T0 and T1 versions don't match, or the T1 is tested for and if that fails it is assumed it is T0...
I am also concerned when/if someone comes up with a printer with more than 2 heads as it is hard coded to T0 and T1 not T(x)...
There is also lots of references to A-codes which I assume have been depreciated but need to be maintained.
Lastly, there is T0 and T1 but E1 and E2, which is sometimes confusing...
This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.
I am reporting an issue that didn't seem to be posted. I am not the compiler for this hardware, so I will need to check upstream to see if it is based on 2.0.8.x or the bugfix version. I was told it had been reported, but when I looked I could find nothing about Homing in the wrong direction.
Please don't wait for me to respond when booking an inspection. I turn off my devices when on appointments and someone else could get your spot. Please CALL our service or book yourself online to save the spot as soon as you know the time you want.
Bob Sisson ACI, BVI Inspections by Bob ASHI Member # 212016 MD Home inspectors License #29666 MAC-ASHI Chapter President 2010-2012 ASHI Mid-Atlantic Group Leader 2009-2012 ASHI National Board Of Directors 2012-2015, 2017,2018-2020 @.*** www.inspectionsbybob.com (301) 208-8289 Scheduling/Pricing
On Thu, Apr 28, 2022 at 3:23 PM Keith Bennett @.***> wrote:
Version of Marlin Firmware Community build based on 2.0.8.x
Please download bugfix-2.0.x https://github.com/MarlinFirmware/Marlin/archive/bugfix-2.0.x.zip to test with the latest code and let us know if you're still having this issue.
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1112574058, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GY32ZY4CIYLFKJ7TLRTVHLQSVANCNFSM5UTMFV6Q . You are receiving this because you authored the thread.Message ID: @.***>
The person who folded this into his machine-specific release is looking into his code.
I found several discrepancies between the source (yours) on GitHub and his in the Advanced_config.H folder
I found it interesting that the T0/T1 commands park correctly, but G27 fails on T1 >> T0. So there is something in either the routine "event ToolChangexy..." or somewhere else in the "Universal tool change settings" section.
[image: image.png]
There APPEARED to be some corruption in several of the routines....
I thought the change to T0 and T1 routines should be identical but reversed, but the code above isn't even close... T1>>T0 uses "G28 A\nG1 A0" while T0
T1 uses "G1 A10"
Bob Sisson ACI, BVI I
On Sun, May 1, 2022 at 11:54 AM InsanityAutomation @.***> wrote:
Still need configuration files, especially the value currently listed in NOZZLE_PARK_POINT. Without that, we will need to point this back to whichever fork this is based off of as it sounds like a misconfiguration and not a bug.
— Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/24100#issuecomment-1114270424, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFJ2GYYPDDTDHEBTDCDSYFLVH2SKNANCNFSM5UTMFV6Q . You are receiving this because you were mentioned.Message ID: @.***>
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Did you test the latest
bugfix-2.0.x
code?Yes, and the problem still exists.
Bug Description
On an IDEX printer (JGMaker Artist) running a version of 2.x
When Switching from one extruder to the other, E1 tries to Home into the Position for E0
The Following commands were executed manually
[Startup]
G28 ; to Zero everyone G1 Z15 X150 Y150 move to a safe place [G1 commands to test movent all worked Fine] T1 {raised the head, and took E0 to the proper position] [G1 commands to test movent all worked Fine] T0 {raised the head, and took E1 to the proper position] tested back and forth, everything worked fine... G27 Worked as expected T1 G1 something to get it out of home G27 RAISED HEAD AND ATTEMPTED TO STORE E1 IN E0'S POSITION
Bug Timeline
bug
Expected behavior
G27 should be aware of which head is active and Park the head in THAT EXTRUDERS HOME.
G27 appears to only know about E0
Actual behavior
G27 attempts to ALWAYS park in E0's position.
Steps to Reproduce
See script in description
Version of Marlin Firmware
Community build based on 2.0.8.x
Printer model
JGMaker Artist-D
Electronics
Stock
Add-ons
No response
Bed Leveling
No response
Your Slicer
Other (explain below)
Host Software
No response
Additional information & file uploads
This is an IDEX issue. Printing with one extruder is flawless. Extruder changes from E0>>E1 work fine. Extruder change from E1 >> E0 crashes the heads together
just calling for an extruder change via "t1" or "t0" works fine
ONLY G27 has a problem.
Tried this with SuperSlicer, Cura and Prusa.
Testing was done with the command line from Reptier to remove slicer(s) from the equation....