Posts made by Aitor

Good morning @dc42,

The endstop cables run close to the stepper motors, and they are also the longest cables on the setup. After the tests I conducted over the weekend, I’ve concluded that the issue is indeed signal interference, likely caused by the motors. Unfortunately, I can’t change the wiring at this time, so I’ll only be able to make this adjustment later on.

As a workaround, is there any way to make all the independent motors stop upon detection by any endstop sensor? If not, could this option be added as G0 H5?

Best regards,

Good morning @droftarts,

In my case, the sensors.endstops[2].triggered object model shows true whenever any endstop is triggered, and I haven’t found an alternative to monitor them individually.

An alternative solution I thought of was to stop all motors whenever any endstop is detected. I tried using the G0 H4 command, hoping it would work this way, but it didn’t. My idea was to send G0 H4 repeatedly and then keep the Z homing as is. My approach would look something like this:

; homez.g
; Homing for the Y-axis

G91                              ; Set to relative positioning
G1 H4 Z{move.axes[2].max} F3000  ; Move
G4 S1
M400
G1 H4 Z{move.axes[2].max} F3000  ; Move
G4 S1
M400
G1 H4 Z{move.axes[2].max} F3000  ; Move
G4 S1
M400
G1 H1 Z{move.axes[2].max} F3000  ; Move
G1 H2 Z-5 F6000                  ; Move
G1 H1 Z{move.axes[2].max/2} F360 ; Move
G90                              ; Set to absolute positioning
M400                             ; Wait for current moves to finish

The pause was just to check if it would work and give me time to react, but H4 did not stop all motors. If it had worked this way, I could avoid any false trigger, and it would only be noticeable in cases where it actually occurred, preventing issues with the Z-axis.

I know my circuit has many connections, but this shouldn’t be an issue. Moreover, I haven’t noticed this behavior in XYU, where X and U have even more connections (two more than Z), so I’d like to think that’s not the case.

Best regards,

Good morning @droftarts,

I activated the internal pull-up resistor, as I mentioned earlier, and it seemed to work well; I completed a cycle of 100 without any issues. To be sure, I then ran a cycle of 1000, but this time it failed on cycle 115 out of 1000. This time, it was Z2 again, but I can confirm that both Z1, Z2, and Z3 have failed at different times. I think it’s unlikely that this is due to the connections. I also checked that the endstop isn’t getting stuck, and it isn’t. So, I’m not sure where this error might be coming from. I also ran this macro for over 12 hours and didn’t get the error message, though the machine was completely stationary during that time.

while true
    if sensors.endstops[2].triggered == true
        break;
M400
M291 R"Final de carrera Z" P"Final de carrera Z pulsado" S2

Best regards,

Good morning @droftarts,

@droftarts said in Issues with Intermittent Stopping of the Z-Axis Motor:

Does the motor stop before any of the motors have hit an endstop? If so, I'd guess the problem was a poor/loose connection in the endstop wiring. Check the wiring to all the endstops. I don't think a pullup helps here, because they are wired NC.

Exactly, my motor stops before reaching the endstop. Before writing this, I checked all my Z-axis connections and replaced all the relevant cables. To give you an idea of how it's connected, my endstop is connected to a custom-designed PCB; from this board, via a flat cable, it goes to another PCB, and from there, two of the motors (Z1 and Z2) connect to another PCB through a different flat cable. From here, the system connects to the Duet3hc, while Z3, due to its location, goes directly to this last PCB.

Today, I am running tests after modifying the Z homing routine, which I changed this way following your recommendation.

; homez.g
; Homing for the Y-axis

G91                              ; Set to relative positioning
G1 H1 Z{move.axes[2].max} F3000  ; Move
G1 H2 Z-5 F6000                  ; Move
G1 H1 Z{move.axes[2].max/2} F360 ; Move
G90                              ; Set to absolute positioning
M400                             ; Wait for current moves to finish

I'm running this testing macro while writing this message, and the Z3 motor failed on loop 53 out of 100. I re-ran the macro, and this time Z2 failed on loop 71 out of 100. In each case, it always fails during homing, never with regular movement commands. Yesterday, I ran this same cycle, moving the Z axis up and down 1000 times without homing, just moving it from position Z0 to Z{move.axes[2].max-1}, and there were no failures, so I can rule out a mechanical cause. As for the error itself, it happened while I was present, and I could see that the motor that stops does not even attempt to move, while the other two, which are always positioned lower, keep trying to move. This is logical since none of them have reached their endstop.

if state.status = "processing" || state.status = "paused"
	M118 S{"Cannot use during "^state.status}
	M99

var cycle = 0
var count = 0
M291 R"Number of Cycles" P"Enter the number of cycles you want to perform" S5 L1 F10
set var.cycle = input
M400
while var.count <= var.cycle
	M118 S{var.count^" of "^var.cycle}
	G28 Z
	G0 Z{move.axes[2].max-20} F{move.axes[2].speed}
	set var.count = var.count+1

On another note, if I wanted to test enabling the internal Pull Up, would it be safe to configure it like this in my case?

M574 Z2 S1 P"^1.io2.in+^1.io1.in+^1.io0.in"                      ; Endstop configuration

Best regards,
Aitor

Good morning @droftarts,

I have reviewed my circuit and can only implement a Pull-Up connection. My intention is to place a 220-ohm resistor from my 5V to io#in. Do you see this as correct?

Best regards,

Good morning @droftarts,

I am experiencing issues with my new equipment using DUET3. The error generally occurs on the Z-axis, which has 3 independent motors, each connected to a different driver and with its respective endstops. Most of the time, it works correctly, but occasionally one of the motors (not always the same one) stops, causing the other two to descend, bending my print bed and preventing further movement.

My NC endstops are two-wire: one connected to GND and the other to io#in. Here is my configuration:

M584 X0.4 Y0.3:0.1 Z1.0:1.1:1.2 U0.5 E0.0:0.2                 ; Set drive mapping
M574 Z2 S1 P"1.io2.in+1.io1.in+1.io0.in"                      ; Set endstop configuration

As you can see, both the endstops and motors are connected to Duet3hc.

My home Z configuration is as follows:

; homez.g
; call to home the Y-axis

G91                                            ; Set to Relative Positioning
G1 H1 Z{move.axes[2].max*2} F3000              ; Move
G1 H2 Z-5 F6000                                ; Move
G1 H1 Z{move.axes[2].max/2} F360               ; Move
G90                                            ; Set to Absolute Positioning
M400                                           ; Wait for current moves to finish

I believe the configuration is correct since it works properly most of the time. However, as I’m experiencing this type of interference, could a pull-up or pull-down connection help? Additionally, I find it odd that on the Y-axis, which also has two independent motors (but connected to Duet6hc), I have not encountered this type of interference.

I would appreciate any input you can provide.

Best regards,

@droftarts said in Possible object model error:

I'm sorry, but you'll have to ask @chrishamm why it works! I think it changes the data type to a string.

ok

Good morning @droftarts,

Your solution worked correctly, but I don't quite understand why. You didn't really add anything by including ^"", did you? What would that be adding here?

Regarding spaces and tabs, I only use tabs, but something might have changed when translating or copying and pasting. My version of the code is in Spanish.

And as for the Panel Due, I was kind of expecting that, but I thought there might be something I didn’t know. It wouldn't be the first time .

Best regards,

Good morning @droftarts,

Thank you for the quick response, I’ll wait then. One more question: is there any way to automatically check the version of the Panel Due, or do I have to do it manually?

Best regards,

Good morning @droftarts,

I was writing a script to verify that my machines are running the correct firmware version, to ensure no mistakes are made. Occasionally, during assembly or when updating the firmware, some Duet components like the WiFi module, expansion boards, or PanelDue might not be mounted. Below is the macro I’ve written, but I’m encountering an issue: the line if boards[0].firmwareVersion == "3.5.3" works correctly, but if boards[1].firmwareVersion == "3.5.3" returns the following error:

M98 P"0:/macros/_MACROS DE FABRICA/0.-Verificación de firmware"
Error: in file macro line 14 column 44: meta command: cannot convert operands to same type

Am I doing something wrong, or is this a different type of error?

if state.status == "processing" || state.status == "paused"
	M118 S{"Cannot be used during "^state.status}
	M99

if boards[0].firmwareVersion == "3.5.3"
	M291 R{boards[0].name} P{"The board is running the CORRECT firmware version. "^boards[0].firmwareVersion} S2
else
	M291 R{boards[0].name} P{"The board is NOT running the correct firmware version. "^boards[0].firmwareVersion} S2
	M291 R{boards[0].name} P{"Firmware installation will proceed: "^boards[0].firmwareFileName} S3
	M997 B0 S0

if exists(boards[1])
	if boards[1].firmwareVersion == "3.5.3"
		M291 R{boards[1].name} P{"The board is running the CORRECT firmware version. "^boards[1].firmwareVersion} S2
	else
		M291 R{boards[1].name} P{"The board is NOT running the correct firmware version. "^boards[1].firmwareVersion} S2
		M291 R{boards[1].name} P{"Firmware installation will proceed: "^boards[1].firmwareFileName} S3
		M997 B1 S0
else
	M291 R"ERROR" P"Duet3HC board not detected" S3

var counter = 10
if exists(network.interfaces[1])
	if network.interfaces[1].state != "active" || network.interfaces[1].state != "idle" || network.interfaces[1].state == "disabled"
		M552 I1 S0
		while true
			if network.interfaces[1].state == "idle" || var.counter <= 0
				break
			else
				G4 P500
				set var.counter = var.counter - 1

	if network.interfaces[1].firmwareVersion == "2.1.0" || network.interfaces[1].state != "active" || network.interfaces[1].state != "idle"
		M291 R{"Module "^network.interfaces[1].type} P{"The "^network.interfaces[1].type^" module is running the CORRECT firmware version: "^network.interfaces[1].firmwareVersion} S2
	else
		M291 R{"Module "^network.interfaces[1].type} P{"The "^network.interfaces[1].type^" module is NOT running the correct firmware version. "^network.interfaces[1].firmwareVersion} S2
		M291 R{"Module "^network.interfaces[1].type} P{"Firmware installation will proceed for the "^network.interfaces[1].type^" module."} S3
		M997 S1
else
	M291 R"ERROR" P"WiFi module not detected" S3

M291 R"PanelDue" P"Please ensure that the PanelDue is running version 3.5.0. Is it on that version?" S4 K{"YES","NO"}
if input == 0
	M291 R"PanelDue" P"You have confirmed that the PanelDue is running version 3.5.0." S2
else
	M291 R"PanelDue" P"Proceeding with PanelDue firmware installation." S3
	M997 S4

Best regards,

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,

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,

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,

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 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 @dc42,

After this test, I wanted to simplify it further by only moving the Y-axis. Here is the code used:

G28
echo >"test" "; Test Start"
var resp = 0
while true
    M291 R"Select Toolhead" P"Specify the toolhead you want to adjust the offsets for" S4 K{"Tool_0","Tool_1","Tool_2","Tool_3","Exit"}
    set var.resp = input
    if var.resp = 4
        break;
    else
        T{var.resp}
        echo >>"test" "T"^state.currentTool^" X="^move.axes[tools[state.currentTool].axes[0][0]].machinePosition^" Y="^move.axes[tools[state.currentTool].axes[1][0]].machinePosition
        G91 G0 Y100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 Y100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 Y100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 Y100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 Y-100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 Y-100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 Y-100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 Y-100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G90
G28

These are the test results:

; Test Start
T0 X=-62.000 Y=375.000
; G91 G0 Y100 G90 executed correctly
; G91 G0 Y-100 G90 executed correctly
T1 X=562.000 Y=375.000
; G91 G0 Y100 G90 executed correctly
; G91 G0 Y-100 G90 executed correctly
T2 X=-62.000 Y=0.000
; G91 G0 Y100 G90 did NOT execute correctly
; G91 G0 Y-100 G90 executed correctly
T3 X=562.000 Y=0.000
; G91 G0 Y100 G90 did NOT execute correctly
; G91 G0 Y-100 G90 executed correctly

The symptoms are the same.

If you think of any other tests I could perform, please let me know. On the other hand, if you find it appropriate, I can try installing the version you have released, 3.5.3-rc.1.

Kind regards,

Good morning @dc42,

Following our discussion yesterday, today I have carried out the following tests for all the heads, executing the macro I generated.

G28
echo >"test" "; Test Start"
var resp = 0
while true
    M291 R"Select Toolhead" P"Specify the toolhead you want to adjust the offsets for" S4 K{"Tool_0","Tool_1","Tool_2","Tool_3","Exit"}
    set var.resp = input
    if var.resp = 4
        break;
    else
        T{var.resp}
        echo >>"test" "T"^state.currentTool^" X="^move.axes[tools[state.currentTool].axes[0][0]].machinePosition^" Y="^move.axes[tools[state.currentTool].axes[1][0]].machinePosition
        G91 G0 X100 Y100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X100 Y100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X100 Y100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X100 Y100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 X-100 Y100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X-100 Y100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X-100 Y100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X-100 Y100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 X-100 Y-100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X-100 Y-100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X-100 Y-100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X-100 Y-100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 X100 Y-100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X100 Y-100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X100 Y-100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X100 Y-100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G90
G28

This was the result of the test I conducted; please note that T# X = starting point position, Y = starting point position.

; Test Start
T0 X=-62.000 Y=375.000
; G91 G0 X100 Y100 G90 executed correctly
; G91 G0 X-100 Y100 G90 executed correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly
T1 X=562.000 Y=375.000
; G91 G0 X100 Y100 G90 executed correctly
; G91 G0 X-100 Y100 G90 executed correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly
T2 X=-62.000 Y=0.000
; G91 G0 X100 Y100 G90 executed correctly
; G91 G0 X-100 Y100 G90 did NOT execute correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly
T3 X=562.000 Y=0.000
; G91 G0 X100 Y100 G90 did NOT execute correctly
; G91 G0 X-100 Y100 G90 executed correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly

In the two combinations where it failed, the previously mentioned noise was heard, but the head practically remains in the same position it was in. In both cases, the expected behavior would have been for the head not to move in X, but to move in Y.

Best regards,

Good morning @dc42,

I forgot to mention that the noise I hear is the same as when I try to manually move the Y(A) axis from the web interface, PanelDue, or M291 X1 Y1, regardless of the distance I try to move. And from here, neither T2 nor T3 works.

Best regards,

Good morning @dc42,

I have reviewed the accelerations, jerk, motor steps, currents, etc., based on the object models, which I find to be the most reliable. If there were any accidental command altering these values, there should be a difference, but in this case, all A[6] values are identical to those of the Y[1] axis.

Regarding what happens when sending G91 G0 X100 Y100 G90, I found the following surprising:

After running homeall.g and selecting tool T2, the command worked correctly since the axis starts from X0 Y0 when homed. Even when sending commands repeatedly and trying to "go beyond" the allowed range, everything behaved as expected, without advancing beyond the configured limits.

However, when doing the same with T3, which starts at X562 and Y0 when homed, I made a mistake by sending G91 G0 X100 Y100 G90. The expected result was for X not to move since that is its maximum limit, and for Y(A) to advance 100 mm. But what actually happened was that neither X nor Y(A) moved; only a small noise, like a loss of steps, could be heard, though not long enough to have moved 100 mm. Despite this, on the DWC panel, the Y and A positions changed to 100.

In contrast, if I home and then send G91 G0 X-100 Y100 G90, everything moves correctly, even when the command is sent repeatedly until it reaches the configured limits, stopping as it should. Furthermore, once the limits are reached, repeatedly sending G91 G0 X100 Y-100 G90 does not cause it to leave the permitted area. I tried several other combinations; for example, if after homing I send G91 G0 X100 Y-100 G90, there is no movement or noise, as expected. In other words, the error only occurs when sending G91 G0 X100 Y100 G90 with tool T3.

This behavior is quite strange and has left me puzzled. If you have any other suggestions for tests I could perform, please let me know.

Best regards,
Equipo de soporte.

Good morning @droftarts,

All the electronics are on the same version, but I am attaching the command responses for you to review.

console.txt

The A axis is on a different board due to the arrangement of the axes and the electronics themselves. I have a 6HC and a 3HC at the rear of the machine, and another 3HC at the front, to minimize the amount of cabling. I don't think this should be affecting the setup since, if it were, it wouldn't work at all. However, I can test what you suggested tomorrow and let you know. I usually try to place at least the "XY" axes on the same board for synchronization purposes, but I think I recall reading that this was no longer necessary, which is why I chose this arrangement at the time. Additionally, it saved me from running cables from one end of the machine to the other, as the space I have for cabling is limited.

If you need more information, please let me know.

Best regards,