Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. Floobydust
    • Profile
    • Following 0
    • Followers 0
    • Topics 2
    • Posts 14
    • Best 0
    • Controversial 0
    • Groups 0

    Floobydust

    @Floobydust

    0
    Reputation
    1
    Profile views
    14
    Posts
    0
    Followers
    0
    Following
    Joined Last Online
    Location Florida, USA

    Floobydust Unfollow Follow

    Latest posts made by Floobydust

    • RE: Wiring a 4 wires PT100 SOLVED

      The PT100 sensor uses a small current flow through the resistive element. As the temperature changes, the resistance of the element changes, resulting in a small change in voltage drop across the resisitve element. As the range is fairly narrow (0.38 ohms per degree C), the longer the pair of wires, the higher degree (no pun intended) of error can result from the resistance of the pair of wires conducting the current. Some PT100 sensors use a third wire. When properly wired, the third wire does not conduct any current and provides accuracy compensation for the measurement. Adding a fourth provide the same accuracy compensation for the other sensor wire. In short, a 4-wire setup will be more accurate, so long as the sensor circuit is properly configured, i.e., two wires are used to drive the current through the sensor and the other two wires are only used to measure the voltage drop across the sensor.

      To connect to the Duet PT100 daughterboard, note that pins 1 and 4 provide the current to drive the sensor and pins 2 and 3 are for sensing the voltage drop. Pins 1 and 2 should be the same end of the sensor and pins 3 and 4 the other end of the sensor. Direction doesn't matter as it's a resistive element.

      If the ferrules don't fit, you obviously need to remove them. Tinning the wire can ease insertion into the connector, but as the connector provides a crimping action, you should be better off not tinning the wires... of course, oxidation over time might result in a slight change depending on your environmental conditions. Personally, I'd probably tin the wires and ensure they are clamped down securely.

      posted in Duet Hardware and wiring
      Floobydustundefined
      Floobydust
    • RE: I'm Now On 5MHz Network, How Do I Use The Duet?

      One option is to get a Raspberry Pi3, which has wireless built in. You can get a 5GHz USB WiFi module and set it up as a WiFI to WiFi router and connect the DuetWiFi that way. Granted, not ideal but functional and fairly cost effective.

      posted in Firmware installation
      Floobydustundefined
      Floobydust
    • RE: DuetWifi for MAC OS

      Yes, I enabled the checkbox for local echo, no issue. I also went and looked at other options. Appears that the Duet interface sends a linefeed character only, so Serial has an option to interpret a linefeed as a linefeed + carriage return. That option resolves the formatting problem, thanks.

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • RE: DuetWifi for MAC OS

      I also use OSX as the main OS for all my machines. As I also do some embedded stuff, I use FTDI USB/Serial interfaces and recently picked up Serial (terminal emulator) for OSX. It's actually a very nice terminal program and flexible. Their website is:

      https://www.decisivetactics.com/products/serial/

      The only thing I have noticed is that when interfacing to the Duet board (via Serial), the data coming from the board is oddly formatted and exhibits endless wrapping in the terminal window (line length too long?). Also, it doesn't echo back any characters sent, which is not a problem, just be aware.

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • RE: Endless messages when printing or simulating

      Brilliant! That did it… thanks for the tip. I even tried putting values in around 20-50 and the same messages appear, so zeros are in.

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • RE: Endless messages when printing or simulating

      Thanks, but no, debug is off in the config.g file. I have logging on, which was done to help diagnose a network dropout, but turning that off doesn't make any difference.

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • Endless messages when printing or simulating

      Okay, I've got pretty much everything sorted and printing nicely with the Duet Wifi board running the mechanics of a Prusa i3 Mk2. However, when I print anything or run simulate against a gcode file, I get endless messages popping up in blocks on the web interface which eventually timeout and scroll off, but it's incredibly annoying. It's always the same content over and over… literally hundreds of them on a small print and seemingly thousands on a larger print. The content is always this:

      Maximum printing acceleration 10000.0, maximum travel acceleration 10000.0

      I'm thinking I've got something setup wrong but I haven't figured it out yet… any ideas? Is there any way to turn this off?

      Also, when running a simulate against a file, the estimated time is not shown on same screen section, I have to switch to the Gcode console to see it. Is there a way to have this display on the same screen simulate is invoked from?

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • RE: New Duet WiFi user

      Thanks David,
      I took a R-Pi3 and configured it as a wireless access point with a DHCP server and linked it to the Xfinity router via ethernet. I configured the Duet to log into this access point instead of the Xfinity router. This does resolve the WiFi module timing out and it's been running fine for a couple days now. So, at least with firmware 1.20 it's a solid connection. Not exactly an elegant workaround but it's functional.

      Similar to another recent post, I've also experienced some occasions when the WiFi module does not connect, either during a cold start or a reboot. It's unclear as to the cause here, but you're in a better position to investigate this. I agree that adding an option to the Duet for retries. Perhaps adding something into the config.g file that allows a time period between retries and an overall retry count. If it fails, simply post a message in the log file, i.e., number of retries failed to connect to a network.

      Panel Due… it's on my list. I'll probably pick one up in the next or two. Is there a difference in the screen content when moving to a larger display (4.3, 5.0 or 7.0) or is really just a larger screen display? I'm thinking about the 5" screen. Any comments welcome.

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • RE: New Duet WiFi user

      Thanks David, I turned on logging and reset the board, etc. It was fine all day long until around 04:12:07 this morning. The log shows the connection as lost, then times out and finally reconnects. I decided to look at the WiFi log on the MacBook and it also shows the connection being re-established at the same time. I started digging into my Comcast/Xfinity service… hard to imagine why, but they do a remotely initiated reset every morning somewhere between 3AM and 4AM!

      Turns out the WiFi module on the Duet doesn't always recover from this. It did this morning and I could reconnect just by clicking on the web interface. I then issued a reset command to the modem via their web interface. Again, the Duet lost it's connection, but this time it showed as having connected but I couldn't connect via the web interface. I had to stop the network, then restart it and was able to connect again. Here's the log file data:

      2018-01-25 13:30:06 Event logging started
      2018-01-25 13:32:51 Event logging stopped
      power up + 00:00:01 Event logging started
      power up + 00:00:01 WiFi module started
      power up + 00:00:09 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
      power up + 00:00:13 HTTP client 10.0.0.33 login succeeded
      2018-01-25 13:33:05 Date and time set at power up + 00:00:13
      2018-01-26 04:12:07 WiFi reported error: Lost connection, auto reconnecting
      2018-01-26 04:12:47 WiFi reported error: Timed out while trying to connect to BSSNext
      2018-01-26 04:12:52 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
      2018-01-26 08:27:35 HTTP client 10.0.0.33 login succeeded
      2018-01-26 08:36:30 WiFi reported error: Lost connection, auto reconnecting
      2018-01-26 08:37:10 WiFi reported error: Timed out while trying to connect to BSSNext
      2018-01-26 08:37:14 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
      2018-01-26 08:40:12 Error retrieving WiFi status message
      2018-01-26 08:40:12 Wifi module is idleBSSNext, IP address 10.0.0.67
      2018-01-26 08:40:15 WiFi reported error: no known networks found
      2018-01-26 08:40:15 Wifi module is idle
      2018-01-26 08:40:43 Wifi module is connected to access point BSSNext, IP address 10.0.0.67
      2018-01-26 08:40:48 HTTP client 10.0.0.33 login succeeded

      Note: after the second reconnect at 08:37:14 I was unable to connect to the Duet via the web interface. I went in via the USB console and stopped/started the WiFi module and was then able to connect via the web interface. To fix things on my end, there's only a handful of options;
      1- Change internet provider 😉
      2- Try manual IP config so the DHCP client isn't trying to reconnect
      3- Add a separate WiFI access point
      4- Turn the Duet off over night and not worry about it.

      Still, there seems to be an intermittent problem with the WiFI module on the Duet, as the reconnect doesn't always work. At least for now the problem is understood. I have an extra R-Pi3 kicking around... I might set it up as wireless access point and connect to it instead and do some additional testing overnight.

      Again, thanks for the great support! Hope the feedback here is useful for some other users as well.

      posted in General Discussion
      Floobydustundefined
      Floobydust
    • RE: New Duet WiFi user

      I continue to experience WiFi module disconnects. It will run for hours, do prints jobs, etc., but will still simply disconnect for no apparent reason. It happened again this morning while idle. I plugged into the USB interface and ran M122 command. The output is shown here:

      m122
      === Diagnostics ===
      Used output buffers: 1 of 32 (14 max)
      === Platform ===
      RepRapFirmware for Duet WiFi version 1.20 running on Duet WiFi 1.0
      Board ID: 08DGM-9568A-F23SD-6JTDG-3SJ6K-1AR7H
      Static ram used: 15448
      Dynamic ram used: 99016
      Recycled dynamic ram: 224
      Stack ram used: 3576 current, 8440 maximum
      Never used ram: 7944
      Last reset 20:55:09 ago, cause: reset button or watchdog
      Last software reset at 2018-01-22 21:21, reason: User, spinning module GCodes, available RAM 7944 bytes (slot 0)
      Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0441f000, BFAR 0xe000ed38, SP 0xffffffff
      Error status: 0
      Free file entries: 10
      SD card 0 detected, interface speed: 20.0MBytes/sec
      SD card longest block write time: 0.0ms
      MCU temperature: min 38.9, current 39.1, max 39.3
      Supply voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0, over voltage events: 0
      Driver 0: standstill, SG min/max not available
      Driver 1: standstill, SG min/max not available
      Driver 2: standstill, SG min/max not available
      Driver 3: standstill, SG min/max not available
      Driver 4: standstill, SG min/max not available
      Date/time: 2018-01-25 06:11:52
      Cache data hit count 4294967295
      Slowest main loop (seconds): 0.160391; fastest: 0.000043
      === Move ===
      MaxReps: 0, StepErrors: 0, FreeDm: 240, MinFreeDm 240, MaxWait: 0ms, Underruns: 0, 0
      Scheduled moves: 9, completed moves: 9
      Bed compensation in use: 5 point
      Bed probe heights: -0.290 -0.190 -0.350 0.145 -0.058
      === Heat ===
      Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
      === GCodes ===
      Segments left: 0
      Stack records: 1 allocated, 0 in use
      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
      serial is ready with "m122" in state(s) 0
      aux is idle in state(s) 0
      daemon is idle in state(s) 0
      queue is idle in state(s) 0
      autopause is idle in state(s) 0
      Code queue is empty.
      Network state is running
      WiFi module is idle
      Failed messages: pending 0, notready 0, noresp 0
      WiFi firmware version 1.20
      WiFi MAC address 60:01:94:34:3e:7a
      WiFi Vcc 3.39, reset reason Turned on by main processor
      WiFi flash size 4194304, free heap 18568
      Socket states: 0 0 0 0 0 0 0 0
      Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)

      I then entered the M552 S1 command as shown:

      M552 S1

      Wifi module is connected to access point BSSNext, IP address 10.0.0.67

      The WiFi module is going into idle mode on it's own, but it's not crashing. Is it possible the WiFi module is intermittant or the server code still has some problems?

      posted in General Discussion
      Floobydustundefined
      Floobydust