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

    Trideo

    @Trideo

    0
    Reputation
    9
    Profile views
    24
    Posts
    2
    Followers
    1
    Following
    Joined Last Online
    Website www.trideo3d.com Location Argentina

    Trideo Unfollow Follow

    Latest posts made by Trideo

    • Duet 2 Wifi - Crash Reboot while printing.

      Hello,

      We've been running our printers with Duet 2 Wifi's for a long time and we are currently having an issue with one of them.

      The board in itself seems to be auto-rebooting after random times while printing a job.

      Hard and Firm specs are the following:

      Duet2 Wifi + Duex5
      Firmware ver 3.3

      We've been using this firmware version + boards + same config files for other machines without issues.

      Debugging data gives us the following information:

      image (3).png image (4).png

      We're currently lost on how to proceed on this one so any suggestion will be appreciated.

      Thanks in advance

      posted in General Discussion
      Trideoundefined
      Trideo
    • Resurrect print - Babystepping issues

      Hello

      We’ve been having issues with our prints when the resurrect print feature is used, specifically in the cases were babystepping has been applied previously.

      We know the babystepping in itself is only meant as an auxiliary tool but in our case we have found there are two use scenarios were its use is necessary for us:

      -When printing with our heated chamber machines as the variations between materials and temperatures often require adjustments in the first layer
      -When printing with our one cubic meter machines as they are located in a warehouse and the bed behaviour varies depending on the climate.

      It’s been noticed that the machine reapplies the babbystepping at the resurrect.g before launching the print.

      232.jpg
      As we do not home the Z axis when the resurrect is launched then the posible outcomes are the following:
      2324.jpg

      Assuming that when there is a power outage the Z will remain at the correct height then reapplying a negative stepping will lead to the nozzle going further into the model and reapplying a positive stepping will lead to the nozzle getting further away from the model.

      Is there any way to avoid this ?

      As the resurrect.g is launched after the resurrect_prologue then we haven´t been able to find a way to clear the babystepping prior to the resuming of the print

      Thanks in advance

      Trideo3D team.

      posted in General Discussion
      Trideoundefined
      Trideo
    • RE: Avoiding accidental homing via screen input while mid-print

      Thanks for the response.

      I have tried similar aproaches.

      The thing is that using "if move.axes[0].homed = true" does not work properly if inserted inside de homex.g as it seems the machine actually resets the X homing value when that function is run and before entering into the code, and that results in move.axes[0].homed being equal to false every time or at least this is what I understood from the different tests I've made.

      posted in Gcode meta commands
      Trideoundefined
      Trideo
    • Avoiding accidental homing via screen input while mid-print

      Hello,

      I'm running a machine using a Duet wifi 1.4 board + Duet extension 5X with firmware version 3.2.

      I've been looking for a way to prevent the user from being able to manually perform a homing sequence once the print has begun or at least create a warning requiring user confirmation ONLY if the printer is already doing something else.

      At the moment I have tried to use meta commands to consult the state of the machine prior to entering the home routine but this has not been successful since when executing the homing itself the machine changes state to "busy".

      I have also tried to query if the machine has already been referenced in a previous home to avoid doing the same again, but it happens that when executing the homing itself, the state of the same is reset.

      I wanted to know if there is any way to achieve this since in our case the machines use a BLTouch as a Z probe and executing a Z homing during a print could result in damage to it.

      Thanks in advance.

      posted in Gcode meta commands
      Trideoundefined
      Trideo
    • RE: PAUSE.G & RESUME.G for IDEX printer (DUAL, DITTO & MIRROR)

      Hi There,

      We are currently running reprap Firmware V3.2, can we speak about this topic as meta command example?
      It will be a useful for us! There is a C, C++ programmer in our team who can't wait to start playing with it!!

      Best regards,

      Simon

      posted in General Discussion
      Trideoundefined
      Trideo
    • RE: 4 Wires BLTouch Connection

      @bearer thanks for answering! About BLTouch connector, we wrote to AntClaBs directly but they newer answered, any news I keep you informed!

      posted in Duet Hardware and wiring
      Trideoundefined
      Trideo
    • RE: 4 Wires BLTouch Connection

      Thanks @Stephen6309, actually we are trying to reduce printer wire types and use a "standard" 4 wires connection for BLTOUCH should help us a lot. Our technical team want to try a 4 wire connection, shorting one negative wire, so before doing a bad move, I preferred to ask here 😉

      Thanks

      Simon

      posted in Duet Hardware and wiring
      Trideoundefined
      Trideo
    • 4 Wires BLTouch Connection

      Hey There,

      Can we connect the BLTouch as shown below? 4 Wires connection?

      f2e71e62-7622-44bc-802c-4bcf43af3ffd-image.png

      Thanks!

      Simon

      posted in Duet Hardware and wiring
      Trideoundefined
      Trideo
    • Run stall detection within home.g during sensorless homing

      Hi there,

      My printer already works very well with stall detection enable for sensorless homing.
      I wanted to make it "safer" to prevent false homing detection during sensorless homing.
      For example, after homing X to Xmin, I want to get X axis to Xmax and during this move, run stall detection to detect any mechanical collision.

      • If the printer go to Xmax without any stall detection events, that significates that Xmin detection did well. Nothing to report
      • if the printer go over Xmax and get a mechanical clash, use stall detection to stop current move, stop homing procedure and also upcoming print and report it.

      Can I do that?

      Thanks for your support,

      Simon

      posted in Gcode meta commands
      Trideoundefined
      Trideo
    • RE: DuetWifi-error: filename too long

      @dc42 Exactly! I'm referring to it "Filename too long" when connected in access Point Mode. We are currently preparing a "migration" to RRF 3.x but it wont be ready until several weeks.
      I would like to give a quick solution to mi clients.
      One of them answered me that he doesn't use Kaspersky AV....
      Thanks for your support !
      Simon

      posted in General Discussion
      Trideoundefined
      Trideo