Support Needed for 4-Head Printer Setup: Y Axis Error
-
@Aitor Have you tried swapping the A axis from the 3HC expansion board to the mainboard? Also, yes, please test with 3.5.3-rc.1.
Ian
-
Good morning @droftarts,
I’ve tried changing the A axis to the main board, but it’s still not working. With heads T2 and T3 selected, if I send G91 G0 Y100 G90, they should move, but they don’t. The only difference now is that I don’t hear any noise when sending the command; before, I did. However, if I send the code G91 G0 A100 G90, it does work.
I’m going to revert to my previous configuration and try installing versions 3.4.5 (which I know worked with another similar setup, although in that case, the A axis was on the main board) and also try version 3.5.3-rc.1.
Note: I’d prefer not to use 3.4.5 if it works, as I use many of the new features in 3.5.
Best regards,
-
Good morning @droftarts,
I don’t know what to think anymore. Before reverting to the previous configuration, I decided to keep my setup as it was, with the A axis on the main board, to resemble the version I tested earlier. The result was that it still doesn’t work. Here’s another issue: in most of my codes, I always use G90, so it’s possible I didn’t realize this wasn’t working. Now, using the macro I mentioned earlier, which I didn’t have in previous models, I’ve noticed the problem. So, I’m not sure if it’s a firmware issue or a configuration problem. I’ll continue testing and will review my entire configuration again. If you have any other suggestions on what I could try, it would be greatly appreciated.
Best regards,
-
Good morning @droftarts,
I’ve tried everything I could think of and reviewed my entire configuration, especially the parts that might be executed when the machine starts up and the files that run before sending G91 G0 Y100 G90, such as tfree#.g, tpost#.g, tpre#.g, homeall.g, config-override.g, and autopower.g (a custom file called from config.g to resume printing after a power loss). However, I don’t see anything that could be causing this error. Additionally, I’ve made sure that in the object models, tools[2].axes[1][0] and tools[3].axes[1][0] are both set to 6 (A), and when I send G90 G0 Y100, these heads respond correctly. Therefore, I’m beginning to suspect it could be a firmware issue that hasn’t been detected until now. @dc42, if you could confirm whether this is possible, I would greatly appreciate it. If you need any additional information, I’d be happy to provide it. Since the machine is for a client, depending on the information you request, I’ll send it to Tony via email.
I’ve also tried the newly released version, and the result is the same.
Best regards,
-
@Aitor I'm pleased to report that @droftarts has now reproduced this issue. We'll fix it in 3.5.3 and in 3.6.0 beta 1 and we'll make a preview available to you early next week so that you can confirm the fix.
-
@Aitor I followed the thread with great interest, because I had no config/toolchange problem with my #hash printer which has 4 independent heads with cartesian kinematics.
I used to use RRF3.2 or 3.3, it might be worth to roll back to these FW versions and verify.
I also used Duet2 and an expansion board, so no possible CAN-address -issues either. -
Good morning @dc42 and @droftarts,
Thank you very much for the help provided. I will keep an eye on the mentioned versions, run the tests, and report back with the results.
@o_lampe, this error does not exist in version 3.3; @droftarts confirmed this for me. Additionally, upon reviewing my notes from a similar model, I found that this issue was indeed present in that version, which is why I didn’t encounter the problem before. However, in that model, I used Duet2 Wifi, so I wasn’t sure if this was the cause.
Thanks again to everyone for the support.
Best regards,
-
@o_lampe I initially tested 3.3, 3.4.6, 3.5.2 and 3.6.0-alpha.5. 3.3 works correctly, while 3.4.6, 3.5.2, 3.6.0-alpha.5 all exhibit the bug, ie individual Y axis move causes mapped axis not to move.
Last night I narrowed it down to changes made in 3.4.2, as 3.4.1 works correctly, but 3.4.2 does not. I can't see anything obvious in the 3.4.2 release notes that would have caused the change in behaviour, though: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-342
Edit: and now, even more specifically, 3.4.2rc2 works correctly, 3.4.2rc3+ does not. For firmware debugging fans, @dc42 suspects this commit, https://github.com/Duet3D/RepRapFirmware/commit/63198ff741ddb2c2c86a49284d5e653fab234dd2, in particular the lines that update and use linearAxesMentioned and rotationalAxesMentioned
Edit: Issue raised on Github: https://github.com/Duet3D/RepRapFirmware/issues/1043
Ian
-
@Aitor Thanks to @AndyE3D, we've found a workaround for this issue. The A axis, though it has been set as a linear axis with the M584 R parameter, is still regarded as a rotational axis in feedrate calculations, and so was being ignored when mapped to an axis with linear feedrate calculations (I think). The workaround is to implicitly set it as an axis with linear feedrate calculations, with the M584 S0, eg:
M584 X0.1 Y0.0 Z1.0 U0.2 V0.3 W0.4 A0.5 R0 S0This seems to get around the issue, and when mapped to the Y axis, the A axis moves correctly, at least for me in testing. It's being fixed in the next release so the S parameter defaults to the R parameter if it is set.
Ian
-
Good morning @droftarts,
I’ve implemented the solution you suggested, and in the initial tests, it seems to be working correctly. If I notice anything unusual, I’ll let you know.
I have a question: when this is fixed in the firmware, should I keep S0 or remove it? Or, on the contrary, does it not matter if I leave it in place?
Best regards,
-
@Aitor you can leave it in place, it won't do any harm.
-
undefined dc42 has marked this topic as solved
