Posts made by Marco Bona

@dc42 thanks, I hadn't thought of this option.

@T3P3Tony because they are occupied by the limit switch sensors.
I would like to add additional overtravel sensors but I only have one input available and I wouldn't want to buy an expansion card just to manage a couple more inputs.
Having said this, I send a single signal from Arduino in order to activate the emergency without using PWMs to identify the error. That's how it should work.

@dc42 No, I'm just using all the IO_IN pin and the CS pins are occupied by the accelerometer.

Hi everyone, I need to connect some overtravel sensors to an external Arduino board in order to send the signal to a single pin as there are no more ports available on the 6HC board and I don't want to buy another expansion board. The idea is to send a signal from the Arduino to the 6HC board in order to activate the emergency when the overtravel sensors are activated.
I wanted to understand if it is possible to manage the signal with different frequencies in order to display a warning message with the axis in error based on the frequency sent by Arduino.
I do the same thing on output using the PWM port of the 6HC board but I couldn't find any help in the documentation.
The only thing that comes to mind is to create an additional Z probe in order to collect the signal, then with a macro I generate the warning based on the value of the signal. Do you think this is possible?

@dc42, hi, I have installed latest internal release, prelease 3.4 beta 3+1 on mainboard while on the expansion board there is the latest release3.4 beta 3, leaving a delay although minimal in the moves it works correctly, the only strange thing that known is that I have to load configuration file 2 times to be able to load the parameters on the expansion board, I don't know if it is due to the fact that some updates are missing on expansion board. With this release I'm getting perfect prints, great job !!

@dc42, now I'm on vacation, I hope to be able to try the new release early next week

@dc42, thanks for reply

@dc42, DSF has also been updated to 3.4.

@dc42, should these versions also work with SBC connected? I tried to upgrade to 3.4 but when I start printing after the print temperature is reached the SBC disconnects and the printout is canceled.I upgraded with unstable branch to 3.4, in version 3.3 it works fine. I'll attach the report after I restart the machine.

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0beta1 (2021-07-10 16:20:28) running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
Used output buffers: 1 of 40 (21 max)
=== RTOS ===
Static ram: 150904
Dynamic ram: 63484 of which 0 recycled
Never used RAM 139804, free system stack 200 words
Tasks: SBC(resourceWait:,2.3%,332) HEAT(delaying,0.0%,325) Move(notifyWait,0.0%,352) CanReceiv(notifyWait,0.0%,799) CanSender(notifyWait,0.0%,374) CanClock(delaying,0.0%,351) TMC(notifyWait,7.3%,93) MAIN(running,89.6%,922) IDLE(ready,0.7%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:00:45 ago, cause: power up
Last software reset at 2021-07-31 18:14, reason: User, GCodes spinning, available RAM 136244, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 144
MCU temperature: min 31.1, current 35.1, max 35.2
Supply voltage: min 24.1, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: position 0, standstill, reads 61046, writes 15 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 61046, writes 15 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 61046, writes 15 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 61047, writes 14 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 61048, writes 14 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 61048, writes 14 timeouts 0, SG min/max 0/0
Date/time: 2021-07-31 18:16:34
Slowest loop: 1.58ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 348, received 316, lost 0, longest wait 1ms for reply type 6042, peak Tx sync delay 179, free buffers 49 (min 48), ts 230/229/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
State: 4, failed transfers: 1, checksum errors: 0
Last transfer: 2ms ago
RX/TX seq numbers: 1585/1585
SPI underruns 0, overruns 0
Disconnects: 0, timeouts: 0, IAP RAM available 0x2c778
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.4-b1
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 60.95, max wait times: 35.8ms/0.0ms
Codes per second: 4.45
Maximum length of RX/TX data transfers: 3481/980

@user3d, hello, I tried to make some prints but I can not give you a certain answer because on expansion board I have 2 axes that I do not usevery often during printing. From what I see I don't think there are any problems but I'm not entirely sure

@dc42 , Thanks.
@User3D , yesterday I did some tests and it seems that adding a G4 between moves gets around the problem. I haven't tried to print but homing works. I enclose an example, let me know if you solve.

G1 H1 U-150 F2000                                                               
G4 P100                                                                         
G1 U5 F1000                                                                     
G4 P100
G1 H1 U-15 F500                                                                
G4 P100                                                                       

With M400 it doesn't work, if you still have problems increase the delay

@Phaedrux ,I wanted to know if there was any update or some solution to fix the problem. I would like to inform you that heater set on the expansion board also has problems with this release.
Furthermore, when starting a print, this error also appeared

Error: Failed to get macro response within 3000ms from SBC (channel File)

I am now working in SBC mode, can anyone give me an answer?
Thank you
Marco

@Phaedrux , @dc42, @chrishamm, I tried in standalone mode, I have the same problem I have with SBC starting from version 3.3RC3 + 7(https://www.dropbox.com/sh/xfsvscbaab0dtzl/AACCcSeiTNINZL-xbs6IhC4Ja?dl=0). Latest release where limit switches work correctly is 3.3 RC3 + 6, if I am not mistaken, afterwards an update was also made on the expansion boards. I cannot provide you with a report in standalone mode because I do not have possibility to connect a network cable to modem, but I am still available for further tests.
Thank you

@dc42, @chrishamm , I try to raise this question to you since I have no longer received an answer.
I think it came from an update between version 3.3rc3 + 6 and 3.3rc3 + 7, if I remember correctly there has been an update on the expansions as well. The stable version has the same problem.

@phaedrux, i tried but i was unsuccessful. Yesterday I forgot to tell you that with the latest update I also reinstalled latest version of DuetPi but I don't think it is related to problem.
If I remember correctly I had a similar problem with RRF3.3 RC3 + 7, but then I had not deepened as stable version was released. With RRF3.3RC3 + 6 I'm sure everything was correct

@phaedrux, sorry but procedure is not very clear, I may have some commands to insert in the SBC otherwise I cannot give you feedback.

@phaedrux, I can try, but I need a procedure having SBC connected, otherwise it is enough to replace files in system folder? Until before update it worked fine

@phaedrux, The states of limit switches are correct, strange thing is that code runs correctly up to G1 H1 U-15 F500, then continues with the code as if the limit switch is active. I have another limit switch on the expansion card that has same problem. On DWC initial screen, axis states are reset after performing the reset. This behavior only affects sensors on expansion board

@jay_s_uk, with delay before M569 I do not get anything different, same problem

@phaedrux , Z axis has 2 motors, it has been like this for about a year and has never given any problems. I know of no alternatives to configuration