3.6.0-beta.3 in CNC Mode Issues

davidjryan

@chrishamm sounds good! I'll test the fix as soon as it's released.

davidjryan

Just saw this from @dc42

@dc42 said in New unofficial 3.6.0-beta.3+4 builds now available:

I have put new builds of RRF 3.6 at https://www.dropbox.com/scl/fo/wyqfqmzj0v7otx6wzqfdl/AJXLaai4nWowqfLtA4gePUk?rlkey=jpyla60xf2tqql0h4nx4sn9yv&dl=0. Please note, these have not been tested as thoroughly as we do for regular beta releases. In particular only the Duet 3 Mini, MB6HC, TOOL1LC, EXP3HC and SZP build have been used for running test prints.

If you have experienced a bug in 3.6.0-beta.3 or subsequent builds then you may wish to try these new builds. Upgrade notes and change list are at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-rc1-in-preparation-changes-since-360-beta3.

Should I try this build? The issue isn't specifically mentioned in the change list but I think it's too small of a bug to warrant a mention.

chrishamm

@davidjryan The required fix will be in DSF 3.6.0-beta.4 which we're still testing internally. Upgrading only RRF will not fix the issue.

chrishamm

@davidjryan Please try again with the new beta 4.

davidjryan

@chrishamm I tried installing 3.6-beta4 on our test rig.

M997 S2 F"unstable" whilst under 3.5.4 did not switch to unstable, so I did this to switch:

sudo rm -f /etc/apt/sources.list.d/duet3d.list
sudo bash -c "echo 'deb https://pkg.duet3d.com/ unstable armv7' > /etc/apt/sources.list.d/duet3d.list"
sudo apt update
sudo apt upgrade

All board firmware, DSF, and DWC installed without intervention.

After a power cycle, I could not get into the DWC webpage. I kept getting the blue Connecting banner and the Red could not connect banner at the bottom of the screen.

I reset the board a few times and powered down and back up and kept getting the same thing.

Another thing I noticed is that the CAN interface did not "come up". All boards were "quick" flashing the Status LED as if they weren't talking CAN to the 6HC ("slow" flash).

To revert back to 3.5.4, I performed:

sudo rm -f /etc/apt/sources.list.d/duet3d.list
sudo bash -c "echo 'deb https://pkg.duet3d.com/ stable armv7' > /etc/apt/sources.list.d/duet3d.list"
sudo apt update
rm -f ./reprapfirmware*.deb
apt download reprapfirmware/stable
sudo dpkg -i --force-depends ./reprapfirmware*.deb
sudo apt install -y --allow-downgrades duetsoftwareframework/stable duetcontrolserver/stable duetwebserver/stable duetpluginservice/stable duettools/stable duetruntime/stable duetwebcontrol/stable duetpimanagementplugin/stable

But... when the firmware update tried to run
sudo dpkg -i --force-depends ./reprapfirmware*.deb
it failed waiting for transfer pin ready

DSF, DWC did revert to 3.5.4 with the last command without issue.
A reboot after that still didn't allow a connection with DWC (3.5.4 DSF/DWC and 3.6.beta4 firmware)

I had to use Bossa to revert the board back to 3.5.4
A reboot after that allowed a connected to DWC.

The Machine-Specifics Electronics showed everything at 3.5.4 except the 3 3HC boards which were at 3.6.beta4
I ran an M997 on B1, B2, and B3, and pushed 3.5.4 to the 3HCs.
After a reboot there, the system is back to 3.5.4 and fully functional.

I'm going to try 3.6.beta4 on my test bench board to see what happens there. Then I can add 3HCs to the mix to see if/where it breaks. If it works there, I'll try the the system again. Maybe there was a glitch updating the 6HC firmware on the first go-around.

If you need me to run specific tests, let me know.

chrishamm

@davidjryan In order to use M997 S2, you must be on the latest Bookworm-based SBC image and the DuetPiManagementPluigin must be loaded. If the latter is the case, that suggests your SBC image is outdated. In that case, I'd propose to flash it again and check if the problem persists.

davidjryan

@chrishamm the test machine is on the 2024-09-19 Duet Pi image. All of our machines are using that image. We have not tried the 2024-11-27 yet since we slow roll updates AFTER our test machine has run for a couple of weeks without issue.

The test bench 6HC took 3.6-beta4 without issue. I added one 3HC and it was able to update.

I am trying our test machine again. If it fails again, I'll try the 2024-11-27 image.

davidjryan

@chrishamm the second attempt to upgrade to 3.6-beta4 on our test machine was successful.

Our machine is operational and we will continue to test it's functionality.

One thing I noticed in DWC while performing a "Home All" are axes 7-13 "re-racking" their order as each axis homes itself. Here is a screen recording of it:
Duet Home All.mp4

Do you want to keep this thread going or switch to a new 3.6-beta4 thread as I run more tests? I believe the original concern is fixed.

I'm going to go ahead and put our test machine on DuetPi 2024-11-27 so we are apples-to-apples going forward.

davidjryan

@chrishamm I spoke a little too soon. The system functionality I spoke of in my previous message was via DWC, not our custom app.

Our custom app relies on python3-dsf-python bindings and it seems they aren't up to date with 3.6-beta4 changes. Or I missed a notation in the changes list for a code change.

When I try to run the dsf-python github example, subscribe_object_model.py, I get an error on:

object_model = subscribe_connection.get_object_model()

It seems like DSF is now expecting something not null in the get_object_model() call

I reverted back to 3.5.4 and all is well.

At the same time, I am now using DuetPi 2024-11-27 on the test machine.

davidjryan

@chrishamm I spoke too soon, again...

So, after I RTFM (read the flipping manual, though it's not flipping), I found I was missing:

pip install dsf-python==3.6.0-b2

Soooooooooo... now I am at 3.6-beta4 for all boards, DSF, DWC, python bindings, etc...

Initial testing of our python app shows functionality.

chrishamm

@davidjryan I just implemented a change in DSF to avoid that re-racking problem.