@usinjin said in Wrong date/time causing HTTP connection issues?:

Sometimes it would fail to load altogether, other times it would load slowly but the connection would reset repeatedly.

@usinjin said in Wrong date/time causing HTTP connection issues?:

I think it could be a hardware issue with the computer or the Duet itself.

@usinjin said in Wrong date/time causing HTTP connection issues?:

It appears that at times ethernet doesn't seem to re-enable after M112 (both lights on ethernet port stay off).

@usinjin said in Wrong date/time causing HTTP connection issues?:

It doesn't seem to matter the firmware. I've installed 3.5.0 rc1, r3, and rc3+4, and they all work until I need to do a board reset. At that point, I just get the error "http failed to connect" over and over again. I always have to power the board off, let it sit, then power it back on.

If I actually took a moment to examine all the information I've presented in this process, I could have addressed the real issue much earlier. I already had all the information and I chose to ignore it. I really should know much better than to fall into thinking traps like this. I guess it could be a learning experience for anyone working closely with hardware and software simultaneously. Or any project for that matter.

It clearly never was a software issue. Wireshark revealed malformed packets and long periods of retransmissions. Definitely not normal on a static network with a single endpoint.

@usinjin said in Wrong date/time causing HTTP connection issues?:

Maybe something is intermittently shorting?

Indeed. Turns out the polyimide tape I bought as a protection for the back of the Duet was not actually polyimide. It most likely is for EMI shielding of some sort, as I found it has a conductive layer. The solder joints on the ethernet port were intermittently coming into contact with it and grounding it out.

After removing the tape, the issues have not re-appeared.

Thank you to everyone who provided insight!

Hello all,

I have an XY pen plotter powered by a Duet 3 Mini 5+ (running 3.5.2). X and Y are stepper axes, a voice coil moves the pen up and down about 6mm. The pen has its own motion controller and is not a registered motion axis on the Duet at the moment. Duet IO signals the external controller to run various subroutines that move the pen up and down.

I recently got a SZP that I currently have attached to the bottom of the "pen carriage" (3D printed structure), and what I'd like to be able to do is build a mesh of the aluminum build plate and be able to use the recorded values to compensate the motion of the pen when it moves down.

Here's the difference in what I'm trying to do, versus the more traditional use for 3D printers. The pen does have a linear encoder that allows it's motion controller to know when it's up or down. However, the way that voice coils tend to operate is their force is directly proportional to the current that passes through their coils (and to some extent, how far they're extended).

In my application, I need as close to a constant force from the pen on the build plate as possible, so instead of driving the pen to some Z position, I apply a constant current to the coil that moves it.

This has worked pretty well in practice, though the value gets a little skewed in places where the build plate isn't perfectly flat. And that's where I think the SZP could help.

Here's my main question (after a lot of rambling): Is there a way to access the mesh compensation values manually during a print? Is there a way to get, for instance, a corrected Z value without having to read the .csv file for the value each time? Is this map loaded into ram when a print starts?

TL,DR: What I'm thinking is along these lines: I have a mesh compensated Z axis that I can use when the pen needs to go down at some X Y location. Maybe the Z will differ from '0' by some amount, and I will take that difference and apply it to the amount of current flowing through the coil. I just don't know where to get the corrected Z from.

Does this mostly make sense? Any advice would be welcome.

@dc42 Running 3.5.0-rc3.

I have built a few XY pen plotters using the Duet platform now (cartesian system, no Z axis) and decided to make one that is closed loop. The past few have worked fine in open loop mode but seeing that I needed to implement external drivers (3x 1HCL boards) and new stepper motors, I decided to give closed loop a shot.

Here's the issue: after tuning the steppers manually according to the wiki, plotted performance is dreadful--the characters plotted are pretty poorly formed. In open loop mode, they are practically perfect quality, but the whole system is much louder and rougher. Closed loop operation (mostly when using the default values, i.e. R100 and everything else 0) is much quieter and smoother, which I'd like to achieve.

3x igus belt driven actuators are driven by steppers with internal quadrature encoders. There is 1x actuator for X, and 2x for Y. The stepper motors I thought seemed a good choice for closed loop control if I was going to use the quadrature encoders and not the Duet magnetic encoder. What's nice about these particular encoders is that they are both incremental and absolute--which may help with a few future applications.

At any rate, the steppers are MinebeaMitsumi M17PMFA34CMB03, 1.5mH inductance per coil and integrated 4000PPR (16000 CPR) quadrature incremental encoders.

I think I'm just not experienced enough to know how to dial in all the closed loop parameters properly. My parameters are set like this:

M569.1 P30.0 T2 C4000 E5:10 R26 I1400 D0.25 V1100 A80000        ; Y0 actuator
M569.1 P31.0 T2 C4000 E5:10 R26 I1400 D0.25 V1100 A80000        ; Y0 actuator
M569.1 P32.0 T2 C4000 E5:10 R16 I1500 D0.25 V400 A40000         ; X actuator

I can share more info about the setup, the tuning process, specifications, etc. I'm not sure where to go from here.

@dc42 VIN fuse. I'll randomly get a communication error with that board and find that it has no power because the fuse is blown. However, it's been a few days and is still good. So I'm not sure what's going on with it.

@usinjin said in Wrong date/time causing HTTP connection issues?:

Sometimes it would fail to load altogether, other times it would load slowly but the connection would reset repeatedly.

@usinjin said in Wrong date/time causing HTTP connection issues?:

I think it could be a hardware issue with the computer or the Duet itself.

@usinjin said in Wrong date/time causing HTTP connection issues?:

It appears that at times ethernet doesn't seem to re-enable after M112 (both lights on ethernet port stay off).

@usinjin said in Wrong date/time causing HTTP connection issues?:

It doesn't seem to matter the firmware. I've installed 3.5.0 rc1, r3, and rc3+4, and they all work until I need to do a board reset. At that point, I just get the error "http failed to connect" over and over again. I always have to power the board off, let it sit, then power it back on.

If I actually took a moment to examine all the information I've presented in this process, I could have addressed the real issue much earlier. I already had all the information and I chose to ignore it. I really should know much better than to fall into thinking traps like this. I guess it could be a learning experience for anyone working closely with hardware and software simultaneously. Or any project for that matter.

It clearly never was a software issue. Wireshark revealed malformed packets and long periods of retransmissions. Definitely not normal on a static network with a single endpoint.

@usinjin said in Wrong date/time causing HTTP connection issues?:

Maybe something is intermittently shorting?

Indeed. Turns out the polyimide tape I bought as a protection for the back of the Duet was not actually polyimide. It most likely is for EMI shielding of some sort, as I found it has a conductive layer. The solder joints on the ethernet port were intermittently coming into contact with it and grounding it out.

After removing the tape, the issues have not re-appeared.

Thank you to everyone who provided insight!

@tristanryerparke MISUMI has a lot of good quality transmission components, I checked and the closest they have is GT2 30T for a 9mm belt.

It doesn't seem to matter the firmware. I've installed 3.5.0 rc1, r3, and rc3+4, and they all work until I need to do a board reset. At that point, I just get the error "http failed to connect" over and over again. I always have to power the board off, let it sit, then power it back on.

This is a board we've been using without issue for months. 3.5.0 rc1 has given us no problems either. The only change is the addition of CAN devices. I'm so stumped.

Man, my latest build hasn't really been going well. My latest problem is with an 1HCL expansion board. I have 3x of them and 1x 1XD running 3.5.0 rc1. The last board (with termination resistors) is the one that blows the VIN fuse about once a week. I've been doing barely any actual moves with it, in fact the whole system has mostly been idle as my DWC spends forever just trying to reconnect...grrr.

The board is supplied with 24VDC and is on standoffs, so there's nothing touching the bottom of the board. No loose wires, not debris on the board that I can see--I'm not sure why this keeps happening. Any ideas I can test? As always any help is appreciated!

@dc42 Well, now of course I can't recreate that--I don't think I had anything connected to any inputs though, and I'm not using any of the 5V_EXT connections anyways. Maybe something is intermittently shorting?

Before, when I was getting 24V on 5V_EXT, 5V_INT was 5V. Now 5V_EXT is back down to 5.29V. (seems a little high as well)

It appears that at times ethernet doesn't seem to re-enable after M112 (both lights on ethernet port stay off). The M569.1 commands are also holding up the reup process, when they are enabled it seems to take the Duet about 20 seconds to come back up instead of about 2. My config.g is below.

Also: 5V_EXT is equal to my VIN (~24V). Why might this be? None of the jumpers have been changed from the factory settings. This may be throwing off my analog sensor reading on IO3, which never reports 0V even with no input. When I take the exact same config and test it with the exact same sensor in IO3 of a different Duet (running the same firmware, same DWC), the input does reach 0V (and 5V_EXT on that board is 5V).

; Configuration file for RepRapFirmware on Duet 3 Mini 5+ Ethernet
; executed by the firmware on start-up

; General
M550 P" " ; set hostname

; Network
M551 P""                                ; set password
M552 P192.168.1.15 S1                   ; enable network and set IP address
M553 P255.255.255.0                     ; set netmask
M554 P192.168.1.1                       ; set gateway
M586 P3 S1                              ; enable HTTP
M586 P1 S1                              ; enable FTP
M586 P2 S1                              ; enable Telnet

; Wait a moment for the CAN expansion boards to start
G4 S3

; 1XD Step Driver
M569 P40.0 S0 R0
M569 P40.0 T2.7:2.7:2.7:2.7
M584 Y40.0 P2
 
; 1HCL Drivers
; Closed loop config
M569.1 P30.0 T2 C4000 E5:10 R100
M569.1 P31.0 T2 C4000 E5:10 R100
M569.1 P32.0 T2 C4000 E5:10 R100

; Start in open loop just for initial home (set known position before calling M569.6 routines)
M569 P30.0 D3 S0  ; driver 30.0 goes backwards (Y0 axis)
M569 P31.0 D3 S1  ; driver 31.0 goes forwards (Y1 axis)
M569 P32.0 D3 S0  ; driver 32.0 goes backwards (X axis)

M584 Y30.0:31.0 X32.0 P2
;  M584 Y30.0 Z31.0 X32.0 P3
M350 X16 Y16 I1
M92 X80 Y59.26
M566 X0.00 Y0.00
M203 X16000.00 Y16000.00
M201 X1200.00 Y1200.00
M906 X2300 Y2300 I0
;  M917 X0 Y0
M17
;  M84 S1 ; Idle timeout

; Kinematics
M669 K0 ; configure Cartesian kinematics

 ; Axis Limits
M208 X0 Y0 S1
M208 X292 Y310 S0

 ; Axis Limits
M208 X0 Y0 S1
M208 X292 Y310 S0

; Endstops
M574 X1 S1 P"^32.io0.in" ; X limit
M574 Y1 S1 P"^30.io0.in" ; Y0 limit
M574 Z1 S1 P"^30.io1.in" ; Y1 limit

; I/O
;   M950 P1 C"io4.out"      ; allocate GPIO port 4 for the triggering of CVM program OR VCA enable (cable must be switched on Copley Controller)
;   M42 P1 S0               ; disable  

; Current-PWM-ctrl for voice coil
M950 P0 C"40.io0.out" Q30000	; allocate GPIO port 0 to out9 on expansion connector, 30kHz
M950 P1 C"40.io2.out"

M42 P1 S0               ; disable motion of pen 
M42 P0 S0.53			; pen up command
M42 P1 S1               ; enable motion of pen
G4 P100

M42 P0 S0.5				; set to 50% (which is 0% output)
M42 P1 S0               ; disable motion of pen

M308 S0 P"io3.in" Y"linear-analog" A"Pen pressure" F0 B0 C174

global pressure_on_pause=0.5
global pen_up_on_pause=0
global pen_is_up=1
global pen_is_on=0
global pressure1=0.44
global pressure32=0.40
global pressure64=0.38
global pressure85=0.36
global pressure105=0.34
global pressure112=0.32
global plot_is_paused=0
global instant=0
global accel=800
global metadata_finished=false
global selected_filename=""
global cancelled=false
global aligned=false