Best posts made by kazolar

@dc42 so we're back the i2c mess. I looked through some other posts regarding i2c -- and I saw some related to not running wires next to or along the ribbon connecting the 2 boards...agh...that's the change that I did make when I added extra cable chains, I changed some wiring paths inside the enclosure. God help me, i2c with duet+duex5 is so glitchy. I re-routed cables around the ribbon, best I could, it's kinda tricky now that the case isn't really designed to do that, but -- OK, I found ways. I just started a print -- same one that failed 2 times yesterday before somehow magically working to completion overnight. Well I am running it now, and all loop times are low -- 3-4ms -- it's early in the print, but that looks promising. So it's not just the heavy grounding wire, but the ribbon needs to be clear of anything -- that might appear to be the issue here -- not defective hardware, or cold solder or firmware -- but cross talk on that ribbon. I'm using some insulated ribbons for my PC -- PCIEX extension ribbons -- they're expensive -- about $30 per, but they have a lot of protection against this kind of cross talk, shielding and such, is that something that is worth considering -- I am going to design a new case to split the duet and duex5 apart from each other the way it's now -- they're one on top of each other (as I believe it's intended) but that leads to some odd wiring runs that make it very difficult to avoid the ribbon.
I will do a triple head print later tonight -- see if that works without a reboot -- so far too far into this duplication print with very low loop times to consider a possible failure.

@dc42 my machine has 2 gantries with 2 independent heads on each. So as I called before a quad. 2 of the tools can be fully independent of each other, z is shared. If there is a way to synch z moves, this would be a cool project.

you adjust your min and max, you have them incorrect for the bed geometry -- keep adjusting them until your center is actually center. G10 is for doing a nozzle offset, which only makes sense for a 2+ extruder machine

I noticed toolchange behavior changed at some point, and am not sure why. Now after postX.g runs z is restored automatically. I don't want it to do that, it doesn't make sense for an IDEX (or more -- I have 4 independent tools) to do that. I lower the bed 0.6mm when I park a tool, and I want it to stay lowered when the new tool comes back to xy position, I have my slicer set to move xy to correct position then adjust z, so I don't want duet to restore Z -- I see this code -- my only option is to comment it out.

		// Restore the original Z axis user position, so that different tool Z offsets work even if the first move after the tool change doesn't have a Z coordinate
		// Only do this if we are running as an FDM printer, because it's not appropriate for CNC machines.
		if (machineType == MachineType::fff)
		{
			currentUserPosition[Z_AXIS] = toolChangeRestorePoint.moveCoords[Z_AXIS];
		}

@dc42 genuine Molex shells and pins have worked and I have not had a single blown connector since switching to them, and have done a lot of calibration routines and started doing test prints again. I also have switched a couple of other steppers to use molex shells -- next time I have to service the controller I'll switch them all. Shame that the stock ones have this issue.

@bberger i think I found the issue. Part mechanical, part software. One of the upgrades I did was move the extruder really close to the hotend -- so the bowden tube is now maybe 25 mm tall, so my previous .02 pressure advance was basically messing up and not extruding where it should be. I tried .01 -- seems better, at least it's not - not extruding, where it should be. The other bit was my extruder sherpa mini which I rebuilt, started had a problem in the MJF glass nylon parts -- replaced with printed ABS body, and like night and day, not perfect, not yet -- I think the stepper got a bit damaged in the process, so needs to be swapped to, and I'll swap all the internal bmg gears to be safe, i think the nylon gear got a bit worn out, but looks like it there was an issue of binding maybe in repeated retractions, and the gears would slip, so the big nylon gear needs to go -- seems the mjf body is not stiff enough or some other property. Pretty sure after I replace all the extruder parts, it will be printing perfectly.

There is nothing I can do in the macros, as based on the code the z position is stored before the macro is executed and z is restored after the other macro is executed...since I have my other tweaks to the firmware that I make to ad additional steppers, I build my own firmware, so I commented this code out. E3d tool changer is not the only multi tool configuration, but even that, s3d issues a specific instruction after the too change to set z, nothing tricky about that, only tricky part is to move it to target XY prior to moving it to z, the key in tool change operations is to restore z AFTER xy is moved to where the next printing operation will happen. I am not sure how firmware can handle it, but my idea was to have gcode which saves z and gcode which restores it, so it can be added in the slicer or macros.

@bot yes. dc42 helped me add 2 more. It's not in the official firmware because is 2 extra ops which would normally not be used by anyone else with a duet 2. It has worked for the last 3+ years perfectly fine. There is a way to reuse the pt100 pins for on duet and duex5. Same way that the LCD pins are being reused for 2 extra steppers.

@dc42 I installed a 14 gauge ground wire -- while at it also did the VIN wire. Both are 1/2 the length they were before, couldn't get shorter than this now. I left the 16 gauge(it was 16 not 18 before) going to the PSU, it's coupled in a ferrule together with a very short 14 gauge jumper to duex5. The printer itself with everything on never pulls more than 200w, since my I'm using an AC bed, 16 gauge wire has not been an issue for 24v DC power.

Now the main question is, how do I test the i2c bus for reliability. Under normal conditions it takes a long time for me to start seeing timeouts, is there a test routine, something that would send a bunch of data on i2c which you would expect to produce some errors if the wiring was at issue (I don't mind running some custom firmware to bang on the i2c bus).

Thanks again.

@3dmntbighker thanks for reprap.htm idea, that worked on my pixel

well that was it -- I just did a bunch of starts and stops of a triple headed print -- trying to re-acquire my z offset and I did not reset anything and the current print is running with normal loop times, this would have inevitably triggered high loop times previously. Good to know no physical defect on anything -- just that ribbon cable must be treated like it's a newborn -- I didn't even think about it when I rerouted all the wires to the 2nd cable chain how they were connecting to where they had to connect to. I am still confused why i2c never showed any errors or timeouts or anything -- just increased the loop time tremendously. Thank you for your patience in sorting this out -- I do wish this ribbon came shielded -- I'd gladly pay extra for a shielded 50 pin cable -- I've been searching for one -- honestly at this point $100 for a cable that would not be bothered by things around it would be a bargain.

yes, that worked -- to keep things simpler i'm just going to use port D and C - the thermocouple port on DueX5 CS pins go to Port E -- so 14 independent (technically I have 16, but there are 2 which run parallel of the LCD port as each of my Y axis uses 2 steppers) -- wohoo! --- Quad independent extruder printer with quad lead screw compensation.

wonder how much of a penalty applying the map to 2 ports vs 1 is... I doubt with the size of my machine I'll ever reach those ludicrous speeds.

@dc42 so the consequence to the 1-byte buffer overflow is the issues I was experiencing. I have applied the firmware this morning. I specifically ran my macro which homes everything except Z to check all movement was fine, then did M18. After that I ran my triplicate print of shields -- worked, 4 hour print, no issues. After that, without a reset I started another triplicate print of 9 shields and I am almost 1 1/2 hours into it, well past the predictable point when errors would have occurred. I could literally time exactly 30 minutes after the lead screw compensation would finish phase warning would start happening. So far, the fix looks like it has worked. Since today is a holiday, I could get the firmware updated and keep printing shields. I'll be able to kick another set of 9 tonight before going to bed, so if 3 in a row succeed...I call it good.

this can be marked solved -- I don't know how to.

That will be more than welcome -- any time-table?
I've taken my circuit to expand the duet and duex5 to the 16 steppers and decided to make it proper -- I needed to have the 2 Y axis steppers in sync -- otherwise the Y axis gantries don't stay parallel, so I made a circuit to skip step pulses when the specific end stop is triggered (and the stepper is moving toward the end stop) -- logic gates -- and the end stop signal going to the duet is a logic and of the 2 end stops -- so duet keeps sending step pulses until both end end stops trigger -- and instead of having 1 stepper bang into the end stop -- even when triggered, it stops receiving step pulses when the end stop is triggered -- it makes more sense on a circuit diagram.. so I ended up taking this combo logic gate circuit and a few other bits and put together a board with 4 end stop inputs, 2 end stop outputs, and 6 stepper driver outputs -- and 3 of those 10 pin headers -- so I can make a clean connection to the duet expansion pin sets -- LCD-CON, and the 2 CS pin headers (on duet and duex5) -- I was planning to mill out the board myself, but I ended up making it to complicated, so I am having it made by jlcpcb. I am going to have 5 of them though -- so ... not sure if anyone will want to use something like this.

@dc42
today with the sandisk card it was
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0

I did what others have asked and took another look at the microSD card solder joints again -- and saw nothing suspicious -- and short of halting everything to pull the board out and stick under my scope and touch up the solder joints -- this doesn't look faulty.
Here is a full res picture
https://www.dropbox.com/s/197mtwcmt2vq6co/SDCard.jpg?dl=0

I was shifting 1 position, wasn't enough, and then I ended up changing the bitmap type to uint64_t -- and shift all the way 32 bits -- that way there is no way to create a clash -- I assumed that's what was happening -- I was just trying to find a way out of having to hunt down everywhere the bitmap is used -- but it wasn't that hard. This works fine now. 14 drivers -- all setup

@T3P3Tony @dc42
Here is where I am at --

1. I am running 2.05RC -- 2.05.1 is a lot less predictable -- it seems to work ok, then stops working and gets into stuttering underrun condition. I can't trust it from print to print, so I went back to 2.05RC -- it's at repeatable, and I can get shields out now without checking on it every 5 minutes.
2. I can tell right away from m122 after the print starts, actually starts laying down plastic -- if I run M122 two times in 30 second intervals, if the 2nd time I get
   Slowest loop: 3.99ms; fastest: 0.08ms
   Then it will work through the end of the print -- I can tell that within 5 minutes now of starting the print before waiting the full 30 minutes to get underruns ans stuttering .
   If I get
   Slowest loop: 63.64ms; fastest: 0.07ms
   Then it will underrun by 30 minute mark.
3. This is what works. I preheated the bed, nozzles -- clean everything off - press reset -- then start the S3D print -- and this works. The print will get slowest loop in 5ms range and will run through to conclusion - 5hrs 15 min give or take.
4. This procedure works -- and has worked for the entire month I've been printing shields until I started messing around with 2.05.1. I don't have to copy the file over, I can keep using the same file.
5. If I do anything prior to starting the print without pressing reset -- I will get the high slowest loop numbers and inevitable underrun.
6. The behavior is absolutely repeatable with S3D or Cura prints (in terms of underrun condition). I am sure I can tune the Cura version to look better, and probably the Prusa version, both looked like trash on layer one to varying degrees -- but both were optimized to eliminate small movements, S3D doesn't have that feature, but this print doesn't have any -- or many.

Question is -- is this hardware or software. I have done triplicate prints before without having to do the "three finger salute" before starting it -- so either something died in the hardware, David's documentation on underrruns talks about voltage regulators, etc. I have no indication that something is wrong there, but the only alteration from then and now, is I switched to optical end stops on XYUVWA axes - the others (for the bed -- are still mechanical). I also went from 32 teeth pulleys to 20 teeth. I have done a 40 hour long multi extrusion print with the current setup with no issues.

@dc42 I installed 3.5 beta 2. The problem appears to have been fixed.