[3.5rc1] 12864 menu issues and multi-stream gcode issues

pfn

I recently updated 2 of my printers to 3.5rc1 yesterday, one of them came from 3.4.5, the other from 3.5b4:

On both printers, my actions file in my menu system no longer function properly, none of the M98 lines execute the macro (https://github.com/pfn/voron2-rrf-config/blob/master/menu/actions). I think I also tried verifying the filelist macros and those didn't work for me, but others on discord were unable to repro.

Additionally, a problem similar to one I previously had in 3.5b2 has re-surfaced (https://forum.duet3d.com/topic/31812/3-5b2-macros-called-from-a-job-lose-parameters). When I use my job-prologue.g as start gcode in my print job, as soon as the heat-wait loop completes, execution jumps ahead to clean-nozzle.g which causes an abort due to either homing not yet being completed, or the print head temperature not being up-to-temp. The abort occurs immediately, but the job-prologue.g continues executing to completion, so the printer then proceeds to home and then set/wait for the nozzle to reach temperature.

Aforementioned files for reference:

I also encountered a problem with canceling a job, I don't recall the exact repro steps, but it is similar to what I previously described in https://forum.duet3d.com/topic/32937/3-5b4-dwc-stops-responding-after-canceling-a-job-on-12864 -- I think I canceled a job on DWC, and thereafter, the printer would not respond to any commands at the 12864 or vice versa.

pfn

It seems the 12864 menu issue is https://github.com/Duet3D/RepRapFirmware/issues/909 I guess we'll see this fixed in rc2? And then I can quote/escape the line to "M98 P""#0""" L"..."? I suppose I could also make the argument embedded in the M98 line...

Going by that, I would expect my macros menu file to be similarly non-functional as that is simply written as "M98 P#0" (https://github.com/pfn/voron2-rrf-config/blob/master/menu/macros)

X-Dron created this issue in Duet3D/RepRapFirmware

closed [Bug]: RepRapFirmware 3.5.0-rc.1 and Screens 12864 #909

dc42

@pfn there are 3.5.0-rc.1+ firmware builds available at https://www.dropbox.com/scl/fo/tjznycpk7bv7sj71p0ssl/h?rlkey=096p4nvgmigyrb20jj8olg3wu&dl=0 which include the fix for this.

gloomyandy

@dc42 I think that @pfn may be using the stm32 port. I'll try and make a recent build available for him to test. Does the most recent source contain a possible fix for the multi-stream problem described above or is this just for the menu issues?

dc42

@gloomyandy yes I think it does - AFAIR Christian implemented a fix to cause both channels to wait for temperature.