Topics created by tristanryerparke

Running 3.6 beta5+1 and the normal test_A_wrap_closed.g, test_A_nowrap_closed.g I got these results:
36.png
I'm now just trying to find a middle ground speed/acceleration combo where the missed steps do not occur, yet isn't prohibitively slow. @dc42 Any ideas on a semi-sealed, magnet-style closed loop motor? Maybe some existing product I could retrofit the duet3d encoder to?

Best,
T

@dc42 On 3.5.2 I'm noticing some different behavior.
This time when the user presses pause while the move_x_macro.g is running, the x axis stops at X=300 and the machine enters a paused state. The macro does not seem to restart upon resuming.
The final line of the macro is G0 X400 which indicates the last movement command is being skipped? I tried adding a G0 X0 to the end of the macro and repeating with the pause, which made the machine stop at X=400. Repeating the G0 X0 did not help either.

EDIT:
I tried adding M400 or G4 P1 at the end of the file as workarounds for the last command issue, but this made the restart issue re-emerge.
Can provide logs again if need be.

Thanks,
T

@tristanryerparke Yes, that is intended. M98 starts the macro successfully but only as soon as the following action fails you get a generic error message. You need to subscribe to the object model to keep track of incoming messages, then you can handle that as well. See here for further API details.

@tristanryerparke Some notes:

Do you need to be able to pause during your injected moves? Pausable macros are terminated when a job is actually paused and they don't resume at the same position. AFAIR the documentation also states that your macro should be able to recover from a pause on its own, so I don't think you gain much by changing to them If you don't need to be able to pause while your custom codes are being executed, consider executing them on the default SBC code channel once all pending codes are gone on File (see Flush command). Codes sent to this channel are not affected by pause/resume. When those codes have been executed, you may resolve your custom code and resume regular file execution DSF generally runs as dsf user. If you turn your script into a plugin, just make sure it has SD write permissions set (see here). If your plugin runs as dsf, it should not require any custom permissions in /opt/dsf/sd either.

My experience with cheap pulleys sourced from China is that the holes are either too large or off center resulting in unwanted motion of the printer mechanism. Idlers that have built-in bearings typically have very small, low quality bearings that won't last, and are likely to have the same off-center hole to mount the bearings. Filastruder sells Gates pulleys that are properly drilled for about $5 each.

If I wanted a toothed idler I would probably buy a Gates pulley, insert a shaft, and mount it in an assembly that uses larger ball bearings. Otherwise, if you don't need toothed idlers, stacked F608 bearings make great pulleys for 10mm belt. They are cheap and will probably last forever in a 3D printer. I've been using them in my printer for 6 or 7 years and they show no signs of problems.

@tristanryerparke not yet.

@gloomyandy MB6HC with 4x 1HCL and 1x 1LC, was on 3.4.6 before.

@dc42 This did not fix the axis drop when sending m18 but it did seem to keep the axis from dropping upon hitting emergency stop.

I also noticed on this belt driven z with the 1HCL that sometimes the axis will drop during tuning using 3.5.0-beta4 (and still with beta4+ from dropbox). I believe I've fixed the issue by increasing the current slightly but if it worked in 3.4.5 with the lower current that would be the ideal situation. Can open a new thread for this if need be.

Overall the new firmware is making my X and Y 1HCL axes run super smooth/quiet and they seem to be able to run much faster than before.

Cheers,
T

@tristanryerparke we plan to implement torque mode experimentally on the EXP1HCL in the near future.

@tristanryerparke I have now tested using 3.5beta3 and the uniqueId field does get populated when I make the CAN connection after powering up both the main board and the SAMMYC21.

The only reason I can see why the uniqueId would not get populated is if the SammyC21 was running firmware earlier than 3.4.0. But in that case the uniqueId field would never be populated.

@tristanryerparke this isn't supported yet but I will add it to the wish list.

I expect to increase the maximum step speed of the EXP1HCL in a future firmware release, and I hope to make it quieter too.

@tristanryerparke we have plans to implement feed hold in a future version of RRF, and that would also facilitate pausing quickly regardless of the jerk. It's pencilled in for release 3.5 but as 3.5 is already late it may have to wait for 3.6.

@tristanryerparke then there's something wrong. What version are you running?

@droftarts Thanks for your quick response.

I just updated to 3.5 Candidate 2 and it seems to be working normally again! I didn't respond so soon because I realised I still need to use FFF mode for the time being.

-Q

@tristanryerparke I will be able to answer your questions better after testing the latest build of the closed loop tuning plugin.

@tristanryerparke there is no native code to do this.

@gloomyandy yes sending G0 E100:200 works perfectly, extruding the specified amount on each extruder.

@tristanryerparke there is a problem passing macro parameters from DSF to RRF in 3.3RC1. Try the RRF 3.3RC1+1 files at https://www.dropbox.com/sh/dlb58vkmu1u4fkx/AAAelkXSfRKVwI6_yqRnhGHPa?dl=0, or the RRF 3.3RC1+2 files at https://www.dropbox.com/sh/urr3rbnawf9ehcq/AAA_frdT0tcOXVlPUz3bHKU8a?dl=0.

I have tested an example similar to yours using the 3.3RC1+2 files in standalone mode. If you still can't get it working in SBC mode using these files then I will ask @chrishamm to take a look.