Pi4Duet3 DCS not started & Proximity inputs into IOx.in


  • administrators

    @BARN-Metal-Fab

    1. Please provide a link to the datasheet or other info for the proximity switches. It sounds to me that they are PNP NC types - is that correct?
    2. Please provide a photo showing how you have wired the proximity switches to the IOx_IN connectors
    3. With the proximity switches connected and 24V power supplied, are you able to access the printer via USB and a terminal emulator program such as YAT?


  • Hi DC42... I'm working on the datasheet (P-switches were gifted by friend who's successfully used them to build this printer's older sister (Pi4 & Duet3). I believe these are NPN rather than PNP.

    Photos will be forthcoming in about 5 minutes.

    I have been successful in connecting to Duet3 with YAT (after powering everything off, then connecting with YAT, then powering everything up). I executed an M122... the results follow here (thanks tonnes for looking!)

    M122<CR>
    === Diagnostics ===
    RepRapFirmware for Duet 3 MB6HC version 3.1.1 running on Duet 3 MB6HC v1.01 or later (SBC mode)
    Board ID: 08DJM-956L2-G43S8-6JTDL-3S46L-1S2QD
    Used output buffers: 1 of 40 (11 max)
    === RTOS ===
    Static ram: 154604
    Dynamic ram: 163100 of which 44 recycled
    Exception stack ram used: 292
    Never used ram: 75176
    Tasks: NETWORK(ready,1980) HEAT(blocked,1200) CanReceiv(suspended,3820) CanSender(suspended,1488) CanClock(blocked,1436) TMC(blocked,204) MAIN(running,5016) IDLE(ready,76)
    Owned mutexes:
    === Platform ===
    Last reset 00:02:19 ago, cause: power up
    Last software reset at 2020-09-02 22:10, reason: User, spinning module LinuxInterface, available RAM 76880 bytes (slot 0)
    Software reset code 0x0010 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0444a000 BFAR 0x00000000 SP 0xffffffff Task MAIN
    Error status: 0
    MCU temperature: min 18.2, current 26.8, max 27.1
    Supply voltage: min 0.4, current 27.0, max 27.1, under voltage events: 0, over voltage events: 0, power good: yes
    12V rail voltage: min 0.0, current 12.1, max 12.2, under voltage events: 0
    Driver 0: standstill, reads 25532, writes 11 timeouts 0, SG min/max 0/0
    Driver 1: standstill, reads 25532, writes 11 timeouts 0, SG min/max 0/0
    Driver 2: standstill, reads 25533, writes 11 timeouts 0, SG min/max 0/0
    Driver 3: standstill, reads 25533, writes 11 timeouts 0, SG min/max 0/0
    Driver 4: standstill, reads 25534, writes 11 timeouts 0, SG min/max 0/0
    Driver 5: standstill, reads 25534, writes 11 timeouts 0, SG min/max 0/0
    Date/time: 2020-09-10 14:37:59
    Slowest loop: 3.85ms; fastest: 0.13ms
    === 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 ===
    Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
    === AuxDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
    === Heat ===
    Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
    === GCodes ===
    Segments left: 0
    Movement lock held by null
    HTTP is idle in state(s) 0
    Telnet is idle in state(s) 0
    File is idle in state(s) 0
    USB is ready with "M122" 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.
    === Network ===
    Slowest loop: 0.47ms; fastest: 0.01ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions Telnet(0), 0 sessions
    HTTP sessions: 0 of 8

    • Ethernet -
      State: disabled
      Error counts: 0 0 0 0 0
      Socket states: 0 0 0 0 0 0 0 0
      === CAN ===
      Messages sent 472, longest wait 0ms for type 0
      === Linux interface ===
      State: 0, failed transfers: 0
      Last transfer: 34ms ago
      RX/TX seq numbers: 3681/3681
      SPI underruns 0, overruns 0
      Number of disconnects: 0
      Buffer RX/TX: 0/0-0
      ok


  • One further point RE: P-Switch assignments. While all three axes' P-switches are connected, I currently have them as "Not Assigned" in Driver config.



  • Here are three images to illustrate wiring:
    1 - Duet & Pi Connections
    2 - 24V (27.2) Distribution of power to P-Switches
    3 - Proximity Switch Signal input to Duet

    Signal wire going only to IOx_in, 24+/- fed to sensors with terminal block (red-24+, blue-24-)

    Thanks again!!1 - Duet & Pi Connections.jpg 3 - P-Switch connection to Duet.jpg 2 - 24V Power Block.jpg



  • I believe I may need to correct the record on PNP v. NPN. With the switch closed, I get 0V between the -24V line & Signal. My reading of the attached image would indicate these Proximity switches are, as DC42 suggested, PNP devices. I interpret this condition to require Drive Mapping Endstop Pin in IO Mapping to set to Active-Low. I'm still working on a datasheet.

    4 - NPN or PNP.jpg

    One additional thing I've tried: I now have the P-switch GND wire connected to the GND input to each of the IO1, IO2, and IO3 connectors, as shown below.

    5 - P-switch connections with signal and GND.jpg

    I have set the Config file Endstop Pin at two separate conditions for Drive X & Y: Not Connected, and IOx_in as Active-Low. In both cases having the P-switches connected to the Duet triggers a DCS not started error.



  • Hi All... still no joy on this problem. But I have a very strange anomaly/repeatability event... this actually happened a couple of weeks ago too when I was first trying to make this work, but I chalked it up to human error; but it's happened again. Here's the sequence:

    1. The machine had been powered off for 2+ days.
    2. The Y-Prox sensor was plugged into IO2 (similar to how it is pictured above, but X-Prox was not connected).
    3. I powered up and DCS started, and I could navigate DWC (thinking hurray... a thread).
    4. I powered down, unplugged Y-Prox from IO2, and plugged X-Prox into IO2).
    5. I powered up and got the DCS not started error (thinking OK... bad sensor).
    6. Powered off, plugged Y-Prox back into IO2 and powered up
    7. And I got the DCS not Started error (Damn!).

    So, same connections, could navigate DWC, then after reconnecting that same successful connection under the same config (no changes), got the DCS not started error and can NOT navigate the DWC. On the off-chance that I had some kind of power stored and electronics were still maintaining some kind of state, I removed 110V power plug, bled the 24V supply by shorting terminals, and tried again: Same Story... DCS not started error.

    I'm totally flummoxed!

    Recommendations?? Do I have a bad Duet3? Replace the Proximity switches??

    Thanks for reading!!
    David


  • Moderator

    Does it work correctly without the proximity switches?

    Does it work correctly in standalone mode?



  • @Phaedrux Yes, when both X- & Y-Prox switches are disconnected, I do not get the DCS error, and can navigate the DWC.

    I've not tried to run stand-alone (without the Pi). Is it as simple as unplugging the ribbon cable and powering up?? Since the touch screen is connected to the Pi, and I connect to the Duet via IP through the Pi, how would I be able to view the DWC, or that matter, even know if the DCS is started?? Connect with the microUSB and launch... what??


  • Moderator

    Standalone mode takes the pi completely out of the equation. I want to know if the proximity switches work correctly in that context.

    You would disconnect the Pi ribbon cable, connect the ethernet direct to the duet3, and you would need a separate SD card with /www folder containing the DWC 3.1.1 files, and a /sys folder containing your config files from the pi /sys folder. You can make a copy of all those config files when you are connected to the DWC. select all the files and right click, download as zip.

    Once the SD card is populated put it in the Duet3 and power it on. If the config.g has a simple M552 S1 in it, the Duet 3 should get a DHCP address from your router.

    You can then connect to it via your browser on a PC with http://duet.local or whatever name you've given the device in config.g. Or get the IP address from the router.



  • @Phaedrux OK... I'll get started on this now. It may be tomorrow before I can post any results. Thanks!!



  • @Phaedrux Hi Again... I worked the problem this afternoon: Built the standalone MicroSD card, set the IP address, and fired up the machine. NOTE: It had been off for 23 hours. One of the P-Switches was connected to IO2. Results:

    -I could ping the IP, and
    -DWC was navigable.

    Turned off the machine, and turned it back on 10 seconds later. Results:

    -No reply from a ping to the IP.
    -DWC not reachable (of course)

    Turned it off, disconnected the P-switch, and powered back up. Results:

    -Reply from ping.
    -DWC navigable.

    Connected the other P-switch to the same IO2, and powered up. Results:

    -No reply from ping, and DWC not available.

    So... the answer to your question is: The system behaves in the same way in Standalone mode as it does in PiDuet mode. Further, the power being off for 20+ hours seems to have some strange effect that allows the DCS to start and DWC to be available on the FIRST power cycle only. The machine will fail 2nd power up cycle. Thus, it appears we have repeatable anomalous behavior (I suspect that's a contradiction in term).

    Thanks again!!
    David


  • Moderator

    Ok thanks. That at least rules out a specific DCS/Pi problem and it's most likely an issue with the proximity sensor itself. Were you able to find a data sheet for it?



  • @Phaedrux I believe the following is the data sheet for the Prox sensors:

    The previous file was empty. Here's the best I can do for a datasheet. It covers a range items in the same product line. Our sensor is highlighted in the PDF: LJ12A3-4-Z/AX Inductive Proximity Sensor Switch NPN DC6V-36V. Output Type NPN NC(normally close)

    Inductive Proximity Sensor LJ12A3_Inductive Proximity Sensor_Photoelectric Sensor_Capacity Sensor_Solid State Relay_PCB Relay_Timer Relay.pdf


  • Moderator

    Thanks. Will have to wait for @dc42 to take a look at the spec sheet.



  • Greetings All... I decided to cut the proverbial knot and ordered replacement Proximity switches ( LJ12A3-4-Z/Ax 4 mm Cylindrical Inductive Proximity Sensor Detection Switch NPN NC DC6-36V 300MA) on the bet that the ones I have were causing the problem. I received the order today and connected two of them to the Duet in the same fashion. The system powered up properly over several cycles. Victory!!

    I consider this issue solved.

    Thanks to everyone who supported me through this ornery problem... much appreciated!!

    David


  • Moderator

    Glad that worked out. Can you tell what the main difference between them is?


Log in to reply