Posts made by gloomyandy

@justGuner Sorry I really have no idea. As I said previously it is very unusual to have 2209 drivers report spurious errors, that almost certainly means that the driver is actually signalling that fault (for whatever reason). If these errors were the result of some sort of random data from the 2209 I would expect to see many read errors being reported and that does not seem to be the case.

If going back to your previously working setup of all 2209s is showing problems that is not a good sign. Has anything else changed? Is there any chance that the 2209 drivers have been supplied with 48V?

@justGuner I'm still confused are you saying that if you go back to a setup that only has 2209 drivers (which was working before) you still get errors? Also when you run these tests are you removing the drivers you are not using from the board? So as I asked above, in test one did you only have the two 5160 drivers installed in the board and you still got errors.

@justGuner I'm a little confused, you said earlier that with just "stock" drivers installed you had no problems is that not the case? Has this board with drivers ever worked correctly? When you get these errors does the m122 output show the drivers are being detected correctly? In your case 1 above are you saying that you only had two 5160 EZ drivers in the board with no other drivers installed and no other drivers configured, but still got errors?

How quickly do you see these errors, it sounds from your later report that you are seeing some of them as soon as the board is used? Has this always been the case (because your earlier posts seemed to indicate that things were working)?

I've really no idea what is causing the faults you are seeing they all sound pretty odd and we have not had any other reports of those sorts of issues. Note: With this board it never makes sense to mix unmodified stepstick 2209 drivers with 5160 drivers as the spi signals will be connected to pins that are not intended to have spi signals connected to them.

@justGuner A few points that may or may not help....

1. It's not a good idea to operate drivers without a motor attached, you will get various "random" errors reported.
2. If SPI based drivers are reporting random errors it may be because of noise or other devices on the spi bus, there is no checksum or crc checks of errors reports over spi. Take particular care with drivers that are external to the board and extend the spi bus via cables.
3. It is very unusual to get spurious error reports from UART based drivers as the messages from the board are protected by a crc (which is checked by RRF). If you get an error from a UART driver there is a good chance that the driver module is reporting that fault (for whatever reason).
4. Remember that the spi signals are always connected to all driver sockets on this board, so it is important when testing to remove any driver modules that are not being using or they may cause problems with the spi bus signals.
5. When using external drivers it is important to keep any wiring to the modules as short as possible and to route it away from any motor wiring.

So it is important to distinguish which drivers are reporting the errors (and the type of driver).

We have had reports of errors being reported with external ez drivers before over on our discord server. Unfortunately the thread is not easy to follow and I'm not sure if it was ever fully resolved. See: https://discord.com/channels/711873626080804914/711873626080804917/1309486826146238474

What drivers are "stock" in your above post? Are they unmodified 2209 stepstick modules? If so I'm surprised that they work, but your modified 2209 modules do not.

@cdoe A quick update, it looks like this is actually a bug in RRF. The rp2040 expansion boards are actually operating in pio mode, but RRF is losing track of that information. It's only obvious if you have a rp2040 based board or are using a mainboard in expansion mode. Current Duet toolboards do not use dma for the led output so they will generate a pause anyway.

The fix is here: https://github.com/Duet3D/RepRapFirmware/commit/5127e951e9b89b9d213de74b66e0dfc261a8ea40 and should be included in furure releases.

However it is almost certainly a good idea to reduce how often you set the led state if you can.

0 dc42 committed to Duet3D/RepRapFirmware

Fixed clearing of DMA-capable flag in M150 to CAN-connected boards

@cdoe As explained here in the M150 documentation:

However, when using an output other than the dedicated LED output on Duet 3 boards, in order to meet the precise timing 
requirement of Neopixel LEDs, RRF waits for all motion to stop and then disables interrupts while sending the LED data.
During this time input data from UARTs may be lost, especially if there are a lot of LEDs to update. Therefore you should use the dedicated LED port if available.

If the output device is not able to use dma to update the pixel then motion will be paused. I don't think any of the existing toolboards (either Duet3D ones or the boards supported by teamgloomy) are configured to use dma output. I think that in theory the rp2040 based boards should be able to use pio mode (a form of dma i/o) to update the pixels but that is not currently the case. I'll take a look at possibly enabling that capability in 3.6, but I will need to verify that it works ok.

For now I suggest that rather than setting the state of the pixels every time through your script loop you modify the code to track the current state of the pixels and only call M150 when things change. That should reduce how often your print needs to pause.

@bug2k22 It looks like the roto board has the ability to load calibration data from NVM, I wonder if the values it is picking up are correct? Might be best to wait for one of the Duet folks to comment further before trying any recalibration though.

https://docs.duet3d.com/User_manual/Connecting_hardware/Temperature_connecting_thermistors_PT1000#semi-automatic-calibration

@magnets99 There are a few other things you may want to consider (sorry this probably makes things more confusing). When a print job starts start.g is executed and (in recent versions of RRF) when it completes stop.g is executed. Some people prefer to use these files rather than having code in the slicer start/end. As others have mentioned you have the choice of managing filament settings either via the slicer or using the system built into RRF. Similarly you can use slicer generated retraction control or use firmware based retraction (to some degree these go hand in hand with filament control).

As you can see there is a theme developing here, some folks like to have very generic gcode being generated and have as much as possible handled by the firmware. This may allow the same gcode file to be used on different machines more easily. Others use the slicer to control pretty much everything. I tend to use a mixture of the two, though because I like to experiment with settings I'm moving towards minimising what the slicer does. But really there is no hard and fast rule.

@RodrigoRMaraujo As Jay has said you can use a different SPI header, though you will need to make up a wiring harness of your own to do this rather than plugging the cables into the exp headers. You will also need to find a pin for CS and pins to supply the board with power.

@jay_s_uk Do we document how to do this anyplace?

NOTE: You can't use a DFD style CAN-FD module at the same time as using a 12864 display, doing so will almost certainly result in the board bootlooping (the DFD and display share the same SPI bus and the long cables to the display cause all sorts of problems with the high speed signals used by the DFD). It is possible to modify a DFD to allow the alternate spi bus on J74, but it may be easier just to use the EFD module to do the same thing.

@RodrigoRMaraujo It looks like it has a STM32F429ZGT6 mcu, in which case yes RRF should run on it. See: https://teamgloomy.github.io/btt_octopus_pro_1.0_f429_general_3_5.html

Before going too far you might also want to spend some time reading some of the background notes on the stm32 port https://teamgloomy.github.io/index.html

@Chriss Have you seen the e3d toolchanger configuration files created by dc42? They may be of interest:
https://github.com/Duet3D/RRF-machine-config-files/tree/master/E3D_Tool_Changer

The associated blog posts might also be worth reading:
https://miscsolutions.wordpress.com/2020/03/02/converting-the-e3d-tool-changer-to-duet-3-with-hemera-tools-part-1/

@justGuner I'm still not sure what you are intending to do.

My understanding is that the problem with this board is that the SPI bus used for the drivers is always connected to the pins on the step stick sockets. This means that if that bus is in use (to talk to spi based drivers) then these pins will be active. Typically stepstick based UART based modules use these pins to configure things like microstepping and other functions and the active spi pins will cause problems for the driver. The EZ style modules for UART based drivers avoid this issue by simply not connecting the SPI pins to the driver chip (which is fine as they are not used for UART based drivers). I think that in theory this means you can mix spi and uart based drivers so long as the UART based drivers are EZ modules, but that is not something I've ever tested.

So I do not think you will be able to use your 2209 drivers if they are stepstick modules. You may be able to get them to work by cutting/removing the pins that would normally connect the stepstick to clk/mosi/miso (do not remove the CS pin as that is used for the UART signal) on the stepstick modules.

None of this impacts 2130 support, we just don't currently support those drivers.

Not something I've ever looked at as the 2130 is a pretty old design these days not offering any advantages over 2209/5160/2240 drivers. You may be able to modify the 5160 driver to support them, but that driver is already fairly complex (which is another reason I've never wanted to add 2130 support). You may just be better selling the 2130s and buying either more 5160s or 2240s (if they are available in the ez format).

@drivetrainsystems Do you actually need to use G28 to home the axis? Could you not simply call a macro to do it (so use M98 to call say home_a.g rather than using G28 a)?

@wayneosdias Once you have a set of readings (saved to a file) you can open that file to check the data. You would normally expect to see X and Y reading around 0 and Z reading around 1 (assuming you have the orientation set correctly and the board is level).

@aceycv8 I'd suggest you post a video showing a print just from just before the pause to just after the resume so folks can see what is happening.

@aceycv8 You seem to be retracting 10mm (in suspend.g) but only extruding 2mm (in resume.g), that does not look right to me.

@speaker2animals How are you measuring the output from e0heat? The signal will be a PWM signal that will basically be pulsing between 0 and 24V (assuming you are measuring between +24V and e0heat the e0heat output is switched on the 0V side), this signal will be pulsing many times a second (the actual frequency can be set with the Q parameter to the M950 command), the amount of "on time" v "off time" of this signal will be changed based on the S parameter to M3, but you will probably not be able to observe this unless you are using something like an oscilloscope or logic analyser to observe the output (don't use a logic probe/analyser unless you know hat you are doing as they may not like the 24V signal). If you are measuring the output with a simple volt meter I suspect it will just seem to be either 0V or 24V.

@Ravihotwok It sounds like what you want is the mechanism described here: https://docs.duet3d.com/User_manual/Reference/Gcodes#examples-173 for Z homing with multiple motors. I'm not sure if the same system is available for other axes or not @droftarts may know.

@gnydick What heater are you using? If it has a particularly heavy set of wires attached to it I'd be checking that it is actually 24V 80W and not 12V 80W. Other than that I'm not really sure what question you are asking. It may be that the heater designers are expecting a long cable run and so have chosen a heavier gauge of wire, but that is probably a question for them.