Topics created by Strider007

@Phaedrux
Thank you. I currently use Cura 5.5.0. I will look over the several files that have exhibited this issue today but I run those same files on two other machines with no bed heater issues. Only this machine exhibits the unreported fault. That is the reason I believe it is something with this specific motherboard rather than the files. It does have driver0 damage; perhaps an EOS event hurt the processor.

Can anyone suggest any diagnostics I could run while printing that might catch this fault? I'm assuming there is a latch or memory location that holds the "heater active" data. Can that be monitored, and capture what's going on?

Yes Cura calls Reprap during file generation.

@droftarts , Yes I realize that now. I found feature request #959 and want to add my voice to the ones requesting this modification. I feel this change could add significant flexibility to M291 by opens up many different options regarding how a query is responded to, or not. Note that is my case I don't even need or want the extra cancel box, but I would live with it if I could get the cancel/timeout to work the way I want it to.

My reason for this request is that I want to reduce the amount of machine cycling as I call macros that contain activity that has already been done and has set flags as to have been completed. The idea is to go ahead and do the extra cycling if there is no response to the query, as a safety mechanism.

FYI, this printer was just posted on Thingiverse as "Core IDX" or as thing:6224372.

@Phaedrux Yes I have researched that link and my drivers were (before HW change) working fine, but that firmware issue with my second board caused my problems. Now the drivers are fixed and working as I need them to.

I have found the auto config not useful at all with my specific design and HW implementation. I needed 8 driver to run 2 carriages and my new 3 motor driver Z axis. I added 3 add on polo drivers (8825s) for the Z. I moved the Z drivers to 5,6,and 7 to maintain common driver motor combos as recommended. With this implementation of drivers, the "auto config" can not compute. I can not make the old Z driver into my new U driver as that option is not allowed (as far as I can see).

Now my only issues relate to my new Z probe (NPN inductive) not working and having gone up to RRF 3.4 I need to figure out how to get 3 point leveling working (reference, pivot, roll) to sync to three motors/drivers but that is no longer a HW or wiring issue so I'll more to a different tread/forum.

Thanks for straightening out my firmware issue! Consider this solved.

@sonderzug, I appreciate your input as I have not been following the latest IDEX designs concepts since about January of 2020, but I had seen a post back in 2019 that had a standard CoreXY design with Markforge carriage and pulleys added to it, and that was part of my inspiration. I believe, ( I'm not a mechanical engineer, just electrical) that the CoreXY style belt routing provides less raking of the Y gantry. Note that I also designed and build a Gli3DR style to see if it would work but I could not get the precision of the CoreXY especially if you are working with a large frame (520 x 510 mm interior) so I settled on this design. I am not surprised that others have found similar ways to implement independent extruders, but since my machine has been operational for 2 years now, I finally decided to basically publish the design and implementation of what I came up with. Better late than never. Here is a photo of the system after it completed a 2 color print
CoreIDX photo.jpg

Great! To move forward I will use the IDEX config as a starting point as it already addresses the homing issues, and put in my own Matrix like I described above. Thank you.