@t3p3tony Oh gotcha, yeah that was a typo in my question, had been testing with "+". Appreciate your responses!

@gloomyandy said in Input shaping testing and thoughts:

I wonder if there is any way that the shaper tuning process could identify and ignore things like this?

I seem to recall it being suggested that the accelerometer could be attached to the frame for a base run and then subtract that from the print head run, but I'm not sure what became of that idea.

@typqxq this is a known issue: heater faults on tool or expansion boards shut down the heater and report their status as "fault", but RRF does not pause the print. This is one of the few remaining items on my TODO list before release 3.4.0 is considered complete.

@dc42 thanks, that worked!

@fcwilt I checked and you are right. The heater state is consistent. The tool state can then be ignored. I see no benefit for now

I got it fixed so the M997 worked great. Not sure what it actually did so if you can tell me so I know for next time. But when I was trying to figure out the heightmap issue I tried putting a mesh.g file in the files. So that was causing the mesh from from working. So deleted the file and works fine now. Thank you for the help. Seems to working fine now.

@chrishamm Thanks a lot, it's smooth now 😄 what's the work-around for prusa slicer please ? if it's an easy one 😄

@t3p3tony @dc42 Sorry for late reply, we are involved in other projects.

We will update to 3.4.0 beta6 now and see if it's gone. By the way, we use SBC mode.

EDIT UPDATE: with the 3.4.0beta6 the missing boards when M999 is still there:

9/11/2021 13:26:47 PRINTER READY, TRY HOMING ALL 9/11/2021 13:26:46 extruder driver: 2 9/11/2021 13:26:42 Error: M584: Driver 40.0 does not exist Driver 41.0 does not exist Driver 42.0 does not exist Driver 43.0 does not exist Driver 44.0 does not exist Driver 45.0 does not exist 9/11/2021 13:26:27 CORS disabled 9/11/2021 13:26:27 CORS disabled

@serbitar The reason is that PrusaSlicer doesn't send the G-code request to start the print in the correct format. I've already prepared a work-around for the next DSF version.

@mckoz said in Software bundle 3.4.0 beta 6 available:

Just attempted a firmware upgrade on Duet 2 Wifi by using the ..github.com/Duet3D/RepRapFirmware/releases/download/3.4.0beta6/Duet2CombinedFirmware.bin. Received the following error:

Error: M997: In-application programming binary "0:/firmware/Duet2_SDiap32_WiFiEth.bin" not found

Cheers,
David

You have to upload the .bin file in the firmware subfolder

@dc42
All connections between the accelerometer and duet were mapped correctly when I checked this morning. However, after re-seating at both ends everything is working as expected. Perhaps one of the wires is intermittently breaking. I used a solid core Cat6 cable and should probably remake with silicon jacketed, braided wire given all the movement.

I assumed that the issue was software because I had tested the accelerometer just before the update and the failure occurred just after. A good example of "correlation doesn't equal causation"!

Thanks for the help and pointing out the obvious thing I should have checked!

😬

@dc42
No problem
I can safely omit the P0
I'll mark as solved pending the next build.

@siam said in Error Upgrading to 3.4.0beta6 on Duet Wifi:

Duet2_SDiap32_WiFiEth.bin

That worked a treat! Thanks very much Slam.

@j3d thanks for reporting that. I'm changing things in 3.4.0beta6 so that a power pin will not be assigned by default, and so io4.out will be free.

@t3p3tony I've tried recreating it by removing the endstop connection, stalling the stepper during homing, etc. etc. but I can't seem to recreate the same error message I've had, and the printer still runs the Z home macro flawlessly. I'm honestly quite perplexed and chalking this one up to RRF beta gremlins 😉

Thanks for the help in all cases!

@sparkie, to check whether everything is communicating properly after startup, you can do any one of the following:

Send M409 K"boards" and look for each board in the response.

Go to DWC, start the Object Model Browser if you haven't already (it's under General -> Built-in plugins), go to the Object Model page and expand "boards". Expect to find all the boards there.

Create a List Boards macro containing the following, and run it:

while iterations < #boards echo "Board type",boards[iterations].shortName,"found at CAN address",boards[iterations].canAddress

Again, this should list all boards in the system.

@dc42 The chamber heaters do bounce around when heating up initially from room temp. To compensate, we've dialed our M307 back to next to nothing. As for the the probe, it's just a run-of-the-mill B3950 thermistor.

M307 H2 B1 C1800 D350 R0.02

The temperature can and does swing negative while initially heating. Some of these faults may be due to momentarily opening the doors to the chamber while heating, but more often than not, the faults occur when the printers have not been touched (and the doors are closed).

We understand the importance of faulting a heater when it's too slow to rise (ex: leaving the doors open), but really would like to see the parameters relaxed while initially heating.. unless there is something more that you can suggest with our M307?

@generisi Nist doesn't mention Q, this seems to be a good letter.

@dc42 It works like it should. My mistake.