I figured out the issue. The cables I was using were crap. Replaced them with a higher quality cable (I bought these from amazon: https://www.amazon.com/dp/B07GD2PHX9?ref=ppx_yo2ov_dt_b_product_details&th=1) and it's working without issues with default sampling rate, resolution, and SPI clock frequency:
M955 P0
Accelerometer 0 type LIS3DH with orientation 50 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000
@phaedrux I had the SDO and SDA pins reversed on the main board. I did a bit more testing and here are the list of symptoms:
The definition of my accelerometer is as follows (in config-override.g):
; Accelerometer
M955 P0 C"spi.cs4+spi.cs3" I50 S1000 R10 Q2000000
The X-move macro:
G1 X-50
G4 S2
G1 X50 F20000
M400
M956 P0 S1000 A0
The Y-Move Macro:
G28 Y
G1 Y40
G4 S2
G1 Y270 F20000
M400
M956 P0 Y S1000 A0
The parameters for the input shaping motion profile capture are shown below:
I rechecked the connections and seemed to made a mistake with the wiring. However, now the accelerometer moves in the X direction when I start the input shaping motion profile, but doesn't do the Y motion. It stops, the motors go idle, and that's it. Even the basic accelerometer data gathering macro now says "Sample,X,Y,Z
Failed to collect data from accelerometer"
I have a Duet 2 Ethernet + Duex 5 on a CoreXY machine running RRF v 3.4.0. The LIS3DH accelerometer is mounted on the heat sink fan shroud with orientation 50 (Z facing -Y and X facing +X). I tested the accelerometer using a simple set of GCode commands (as outlined on the Duet3d Documentation site) and the CSV file captured the data with no issues. I then installed the input shaping plugin and followed the instructions on the Duet 3D Documentation website. However, when I went to create a motion profile, the connection to my printer is reset and the board basically restarts. I've added some screenshots showing what happens. Any ideas as to what the issue could be?
@phaedrux It does seem like an Ethernet controller problem. The SD card from the problem board works just fine on my spare Duet 2 Ethernet.
I tried resoldering the ethernet module pins to the board, but to no avail. When the board is first powered through USB, the module lights up. When I issue an M552 S0 to turn off networking, the module lights go out. When I enter M552 S1 to enable the network, the lights don't come back on. At this point I can't be certain if it's the main board or the ethernet module. Guess I'm going to have to switch it back to WiFi to confirm.
I will use my spare board in the meantime.
Thanks!
@phaedrux Yes, it lights up (Yellow light is solid and green light blinks randomly). I have a spare Duet 2 Ethernet and am testing with the SD card from the problem board into the spare board to see if the issue repeats itself.
I'm using a Duet2 Ethernet with a Duex5 Expansion board for one of my new builds and am having trouble with the ethernet connection. The configuration is set to acquire a dynamic IP, but it is not getting an IP assigned. I connected to the board through YAT and get the following message:
Network is enabled, configured IP address: 0.0.0.0, actual IP address: 0.0.0.0
I then issue an M552 S0 to turn off the network and restart it using command M552 S1, but the ethernet module doesn't seem to turn on. I have to disconnect and reconnect the USB for it to restart the ethernet module.
FYI - This is a Duet Wifi board that I converted to ethernet. During initial testing automatic IP assignment seemed to work fine, but after installation on the printer, I can't get it to work. I have restarted my router, even tried a manual IP assignment in the config file as well as on the DHCP list on my router, but to no avail.
When I assign a static IP in the config.g file and connect via USB on YAT, I get the following message repeatedly on my screen:
Network is enabled, configured IP address: 192.168.1.188, actual IP address: 192.168.1.188 (This message keeps repeating with no end).
Even with the message repeating, when I try to launch DWC, it doesn't connect. Any ideas as to what the issue may be? Do I need to format the SD, and rebuild the configuration files?
@owend quick question. I'm assuming move.axes(2) refers to motor driver 2 which is usually mapped to the Z axis. What if I have multiple independent Z (my printer has drives 5, 6, and 7 mapped to z on a Duex 5)? Can I use any one of those drive numbers?
@owend This is super cool! I didn't know RRF supported conditional GCode. Now I need to learn how to program in this language.
Thanks a bunch!
I was wondering if the microcontrollers on the Duet 2 or Duet 3 have enough memory so that the max Z height from the last print is stored in memory before the print is finished. This way, when a new print is started and the printer has to home on Z, it can recall that saved height and start from a potentially known position (not as an accurate height, but a starting point of reference to assist with homing). This can avoid overtravel since most homing moves require the Z axis to move away from the print head (usually 5 or 10 mm) and if the prior print used the printer's full Z capacity, then there would be no more Z travel left and it puts unnecessary strain on the motors.
If this value can be stored, is there a way it can be stored using ending G-Code?
@deckingman thanks for the info! This is certainly a step in the right direction for me. However, instead of an emergency stop when the max limits are triggered, I want the axis that triggered the max limit to just stop moving and continue with the rest of the Gcode. The only situation where this will be a concern for me is while homing the axes. So if Z max is triggered, the Z axis should stop, the printer should continue homing X and Y and then home Z. My X and Y axes don't have the issue of max limits being triggered because the frame is designed in a way that encapsulates the end of the linear rails for these axes and the carriage blocks cannot dislodge from them.
I'll look into the different trigger config options on the M581 command and experiment with them.
Thanks a bunch!
I am using a Duet 2 Wifi + Duex 5 on a CoreXY printer from SecKit Designs (The SecKit SK-Tank) and I noticed that the linear rail positioning and frame size make it so that carriage block reaches the end of the rail at the max range of the Z axis. Normally, I would program the max coordinates in RRF configuration to prevent the axes from going over, but when the printer is shut down and started up with the bed at a random position, the homing sequence moves the Z axis before homing the X and Y. This can cause the carriage blocks to dislodge from the rail if the Z axis is close to max position before the homing sequence starts.
In order to mitigate this, I was wondering if we could program and set up an endstop for Z max as well so that motion on the Z axis stops if the Z max end stop is triggered. I have extra endstop channels in the Duex 5, so was wondering how I would set up my config file for this.
Any help would be appreciated.
Thank you.
I followed your advice and I am now getting consistent readings within 0.005mm which is well within the margin of error for the probe. The key was the probing speed and the dive height (Set to 5mm/s and set to 5mm). Once I slowed the probe down and also didn't raise the Z height above 5 mm, the readings were consistent.
Thanks for the advice!
@SupraGuy Hmmm....I do have HTP Stove paint...
@Phaedrux Thanks for the tips. I'm using the BuildTak flexplate with a black coating on the sheet steel, so I don't think it's related to transparency/translucency of the bed material, but the surface is rough (to enable better adhesion I suppose), so I will use a piece of matte paper to see if that changes anything.
My standard Z homing is based on the center (updated in homez.g and homeall.g to make sure probe is at bed center). I will move to the bed center and try tuning the trigger height.
My dive speed is set to 10mm/s. I'll try slowing it to half that (been meaning to do that anyway, so now's as good a time as any)
I like the idea of throwing out the outliers and taking an average or modal value.
Thanks for the tips! Will update the thread based on the results.
Hi,
I'm following the "Test and Calibrate a Z probe" tutorial on the Duet Wiki (https://duet3d.dozuki.com/Wiki/Test_and_calibrate_the_Z_probe) and I'm running into minor inconsistencies with the trigger height. The wiki says that after we bring the nozzle down to touch the build plate or just grab a piece of paper (I'm using a sheet of printer paper), to reset z to 0 (G92 Z0) , move z up 5 to 10 mm (G1 Z5) and run a G30 S-1 to get the trigger height and to repeat these series of steps 4 or 5 times.
I'm trying to get my Z trigger height near the bed 0,0 position (sensor is 5mm in from both X and Y edges) as I want to see the height map relative to the bed origin. After I get the nozzle to the right height, I send G92 Z0, move Z up 5mm, run the G30 S-1 and get a trigger height value. I then move Z down by the trigger height value to make sure it doesn't over travel and that there isn't excess pressure on the paper, re-zero Z, and repeat. The second time, the trigger height is completely different. Here are the values I'm getting:
1st try: Trigger height 0.855mm
2nd try: Trigger height 0.840mm
3rd try: Trigger height 0.837mm
4th try: Trigger height 0.848mm
5th try: Trigger height 0.795mm
6th try: Trigger height 0.822mm
Would these values be considered within margin of error for the IR probe? The website for the probe (https://miscsolutions.wordpress.com/mini-height-sensor-board/) states that the repeatability should be approximately 0.01mm, but I'm getting a variance between 0.003mm and 0.06mm which I think is a massive swing.
Any ideas how I can bring the numbers closer together? Also, what should I use as the trigger value? The last obtained trigger height?
@droftarts Honestly, Kapton on glass is pretty awesome since all you need is a bit of glue stick and stuff just sticks to it.
@droftarts Thanks. The PEX comes pre-applied to the bed surface. I may just opt for the BuildTak Flex plate system seeing as the BuildTak system comes with a black sheet (not sure what material it is but it's not PEI or PEX) that you manually have to apply to the spring steel. I'm currently using it on my printer and the IR sensor has no issues. However, I'm upgrading my bed to a 6mm MIC6 bed with a silicone heater so need a new flexplate system to add to ti. And it is similar in price to the WhamBam system for the bed dimensions I need
Hi,
I'm considering buying the WhamBam flexible build plate for my printer and the removable surface comes pre-coated with PEX. I also use the dc42 mini differential IR sensor for bed leveling. Is anyone aware of whether this will pose any issues with an IR sensor? I read that PEI is highly transparent to IR, but not sure if that's also the case with PEX.