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

    Posts made by aze

    • Help implementing a unsynchronized continous axis

      Hi, Im working on a project where i need to incorporate a continously rotating axis at a specific RPM. It is a Nema11 stepper motor mounted on the toolhead, on a modified E3D Toolchanger. I´ve seen several threads on multiple motions systems, but I cant seem to understand how i would implements this.

      The XYZC will run regular gcode, but while that is running, i want to be able to have the NEMA11 running continously at a specified RPM.

      I understand that this might be possible to implement with the Duet 3 boards, but im running Duet2 Wifi on all my machines. I talked to David during Formnext last year and got the impression that this could be possible to implement, but I did not get exactly how.

      The rotation could be started manually before I start my printing gcode, with a simple macro where the RPM is defined, and I can manually turn it off with another script after my printing is done.

      Im currently running it with a separate driver via a RPi, but i would be alot neater if I could just use one of my spare drivers on the Duet 2 WiFi or Duex5 board.

      Thanks in advance!

      posted in General Discussion
      azeundefined
      aze
    • RE: Bed movement after toolchange dispite lack of commands

      @fcwilt

      Hi, thank your for your answer, I will supply complete files when at work and has access to the files. For hte time being, Im running the toolchanger with a Duet Wifi 2 and Duex expansion board, and RRF3.xx firmware.

      @jay_s_uk
      Where in the documentation can I find more information about this? I find it odd that that since RRF should be "everything g-code" I would expect to find the actual g-code command instructning the printer that leads to this behaviour. If this is not the case, troubleshooting because very hard in my opinion. If this is a desired behaviour, why not put it in the tpre/post/free so users can identify the source of the behaviour? Im sure there are good reasons for not doing this, but Im just asking out of curiosity.

      I dont want to apply tool offsets, since im using an automatic tool offset calibration setup as develop by Danal Estes: https://github.com/DanalEstes/TAMV. For me it would be easier if I can start without any offsets applied and let the automatic calibration take care of that.

      Anyway, thank your for your input! I´ll supply more information when Im an work.

      Best regards
      aze

      posted in Using Duet Controllers
      azeundefined
      aze
    • Bed movement after toolchange dispite lack of commands

      Hi, Im working on a E3D toolchanger and Im having problems with erratic behaviour after a toolchange.

      I have disabled all tool offsets in config, like this:
      G10 P0 X0 Y0 Z0
      G10 P1 X0 Y0 Z0
      G10 P2 X0 Y0 Z0
      G10 P3 X0 Y0 Z0

      I start the machine and home all the axes. No tools are selected at this point. I then send T2 to pickup the tool, which initiates the tpre2.g file, containing the instructions to move to the dock, lock the tool to the toolhead and move out. I´ve added a G1 Z150 F2500 in the end of the tpre2, to lower the bed before the move out from the tooldock, to make sure the tool does not crash into the bed.

      After this I expect tpost2.g to be run, but I´ve removed all the content so nothing more should happen.

      At this point I would expect nothing more to happen until I give further instructions to the printer.

      What happens is that the build plate is moved up to the position where it was before the toolchange was initiated. I think this could be a result of a G1 R2 command somewhere, which tells the printer to go back to the position it was when the tool change was initiated. But no such command is present neither in the tpre2 or the tpost2.

      I can not figure out what is the origin of this movement is. Am I misunderstanding something or have I stumbled upon a bug of some sort?

      Best regards

      aze

      posted in Using Duet Controllers
      azeundefined
      aze