Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. kraegar
    • Profile
    • Following 0
    • Followers 1
    • Topics 31
    • Posts 527
    • Best 32
    • Controversial 1
    • Groups 0

    kraegar

    @kraegar

    51
    Reputation
    57
    Profile views
    527
    Posts
    1
    Followers
    0
    Following
    Joined Last Online

    kraegar Unfollow Follow

    Best posts made by kraegar

    • RE: RailCore II corexy

      I’m pleased to be able to make a major announcement!

      KITS ARE ON THE WAY!

      We’re partnering up with Project R3d to make RailCore II kits a thing.

      What this means for the Open Source RailCore:
      The RailCore will remain Open Source. The BOM, Build Guide, and fusion models will remain published as they are, and will be updated as we make changes. Nothing changes at all there, all future adding and improvements will be compatible with existing RailCores. The option of self-source building will remain available.

      So what are the kits?
      To the largest extent possible Project R3d intends to offer a “True to the BOM” 300ZL kit - the final components aren’t 100% done, and some minor changes will be necessary, but overall it will be the same RailCore you can get today, just with “one click shopping”.

      What to expect in the kit:
      Duet & Duex5 electronics will be included.
      A wiring harness to simplify wiring to the Y carriage. Cables cut to length and pre-crimped.
      Aluminum parts including the Bed, Stepper Mounts, Idler Plates, and X-carriages. (Still sourced from 713maker & Mandala whenever possible)
      Various options for hotnends including E3dv6, Mosquito, or no hotend. (so you can “bring your own”)
      Options for an extruder or a Bondtech BMG, or no extruder (so you can “bring your own”)
      The bulk of the parts will look much as they do today - right off the BOM, and the printed parts done in Atomic filament (CF PETG for the structural parts).
      Pricing is expected to fall between $1300 - $1700, and has not been finalized.
      The timeframe for kits has not been finalized, but we're hoping within the next 1 - 2 months for the initial batch.
      Project R3d will provide hardware support, J. Steve White & myself will continue to provide build support & continue with R&D to keep making the RailCore better. 713Maker & Mandala Roseworks will continue to be partners, without them we wouldn't be as far as we are.

      Next steps are putting together a forum (we’ll move off of SeeMeCNC’s) to offer support & info (we’ll keep the Facebook group alive too) and work on touching up the documentation. The initial batch of 10 kits will be coming in the next few weeks, and will be used to test out the process, catch any issues, etc.

      We’re looking for feedback from the community - what do you want in a kit? What questions do you have?

      We’re looking forward to the partnership with Project R3d, and to see the RailCore II be made accessible to a wider audience!

      Tony Akens
      J. Steve White
      Joe Podgorski - Project R3d

      posted in My Duet controlled machine
      kraegarundefined
      kraegar
    • Auto-Tramming a RailCore Using conditional GCode

      So, here's how I'm iterating through auto-tramming to level a RailCore. This can be cleaned up once we have variables, but even still, it's very cool (and confirmed working)!

      First, to simplify, I moved my "G32" commands for probing the bed into a macro called "bedlevel". So I can use that like a function. (Feature request: can we send arguments to macros? Then they really would be functions!)

      ;bedlevel
      ;Call from auto-level Routine in bed.g
      
      ;Run initial 4 point leveling routine
      G30 P0 X15 Y45 Z-99999
      G30 P1 X15 Y275 Z-99999
      ;G30 P2 X275 Y150 Z-99999 S3
      G30 P2 X275 Y275 Z-99999
      G30 P3 X275 Y45 Z-99999 S3
      

      Now that those commands are there, the following can go in your bed.g
      The goal is to level across the bed to a deviation of < 0.01, and then do another round, and have that round within 0.005 of the previous. If not, it repeats.

      M561                         ; clear any existing bed transform
      ; If the printer hasn't been homed, home it
      if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
        G28
      
      ;Move up 7.5mm in Z to clear the bed  
      G1 Z7.5
      
      ;Run an initial auto-tramming
      M98 P"/macros/bedlevel"
      
      while true
        if iterations = 5
          abort "Too many auto calibration attempts"
        if move.initialDeviation.deviation < 0.01 
          if move.calibrationDeviation.deviation < move.initialDeviation.deviation + 0.005
            if move.calibrationDeviation.deviation > move.initialDeviation.deviation - 0.005
              break
        echo "Repeating calibration because initial deviation (" ^ move.initialDeviation.deviation ^ "mm) must be < 0.01"
        echo "and (" ^ move.calibrationDeviation.deviation ^ "mm) must be within 0.005 of initialDeviation"
      
        M98 P"/macros/bedlevel"
      
      echo "Auto calibration successful, deviation", move.calibrationDeviation.deviation ^ "mm"
      echo "Auto calibration successful, initialDeviation", move.initialDeviation.deviation ^ "mm"  
          
      G28 Z
      
      G1 X0 Y0 F24000
      
      posted in Gcode meta commands
      kraegarundefined
      kraegar
    • M220 apply to only printing moves

      Since M204 can be changed for travel or printing moves, RRF is obviously making a distinction, likely based upon if a move is only in X/Y or if it adds an E value. So I'm wondering if M220 can also be applied only to printing moves, and not travel moves? Most times I just want to slow my print to allow for better cooling, but not slow my travel moves (and retractions, or firmware retractions anyway).

      Similar results may be possible by other means, if so, I'm open to suggestions!

      posted in Firmware wishlist
      kraegarundefined
      kraegar
    • RE: Rigid vs Flexible Couplers for Trapezoidal Leadscrews?

      I did lots of testing on the railcore with various leadscrew couplers. (Two brands of spring style, two brands of rigid, two brands of the 3 part oldham couplers with the red plastic, and one brand of double disk diaphragm couplers).

      I tested using my straightest leadscrews & some that were far less straight, in varying configurations. I used both printed and aluminum yokes (that tie our bed to the leadscrew & Z linear rails)

      I found the following:

      Spring Style - loudest. Cause Z artifacts on rapid z-hop, least consistent Z probes.
      Rigid couplers - Worst transmitted artificats if you have a bent leadscrew. Also hard to align due to most of them having the grubs opposite each other.
      Oldham - Best of the "common" couplers, quiet with the least artifacts transmitted. Cheap ones separate easily.
      Double Disk - Overkill for common 3d printing use. Comparable print quality to the oldham couplers.

      I now recommend folks go with good oldham couplers. Zyltech is a good source for them.

      Hope this helps!

      Edit: Oh, my test print is a spiral vase cylinder, only 30mm in diamater, at least half the height of the bed. Couplers transmitting wobble will show up as a wave pattern with the same period as your leadscrews, in my case 4mm.

      Second edit: I've been told misumi sells even nicer oldham couplers, but I have not spent the $ to try them. Part # MCO15-5-8

      posted in General Discussion
      kraegarundefined
      kraegar
    • RE: Rigid vs Flexible Couplers for Trapezoidal Leadscrews?

      Did some digging and turned up this:

      https://www.ruland.com/resources/technical-articles/technical-article-servo-coupling

      Indeed, I was using the wrong term for the ones from Zyltech. I'll leave my error to avoid confusion. (also, helpful article)

      posted in General Discussion
      kraegarundefined
      kraegar
    • RE: RailCore II corexy

      We're "officially" considering the Standard builds deprecated, in favor of the ZL models (250ZL, 300ZL, 300ZLT). I've marked the Build Guides & BOM's to reflect that, as well as updated the table on kraegar.com. I'll be updating thingiverse accordingly and re-organizing the files in line with this change.

      The standard builds will remain published (fusion files, guides, BOM) as they are now, but I won't be making a continued effort to keep the links and information in them up to date.

      This is being done because the vast majority of the interest in the RailCore is now geared towards the ZL, and it will save a lot of time to just focus on the documentation and BOM's for those models, as well as to plan future updates with only needing to worry about those designs.

      posted in My Duet controlled machine
      kraegarundefined
      kraegar
    • Duet3 and Hotend fans on reboot

      So, I power my pi off of my duet3 currently, and it's troubling that when I reboot the pi there's a long delay while it boots before the hotend fan turns on. I know I can set the pi to be externally powered, but still, there will be that chance of a reboot while my hotend is at temp. What is the best option for dealing with this so we don't get heat creep during reboots?

      posted in General Discussion
      kraegarundefined
      kraegar
    • RE: RailCore II corexy

      The halo files will be released once they've been tested on a 300zl, and confirmed to work. Then I'll clean up a lot of cruft from the design, and publish it. Probably within a week or so of testing, depending on my work schedule.

      posted in My Duet controlled machine
      kraegarundefined
      kraegar
    • Delta Effector Tilt Measurement

      I've been using a spirit level for a while to measure tilt, but wanted to get more accurate. So I found a way to use a gyroscope/accelerometer breakout to measure it.

      This involves a separate arduino outside of the duet. The code is from the example here: https://github.com/TKJElectronics/KalmanFilter

      I used the adafruit breakout here: https://learn.adafruit.com/adafruit-lsm9ds0-accelerometer-gyro-magnetometer-9-dof-breakouts/wiring-and-test?view=all#overview

      You just install the code on the arduino (customize for your breakout if you use a different one) and clip the breakout rigidly to your effector. Then move your effector around, and measure by watching the serial monitor. Definitive numbers, a measurement of tilt at any point on your printer. (The code at its start measures the current angle, and uses that as the reference, it gives two sets of two numbers… angle measures, and deviation from the reference).

      My printer measures a pitch range of -0.1 to 0.1 degrees, and a roll range of -0.1 to 0.4 degrees of tilt. (My "worst" point is when my effector is at 0,-135)

      Here's the code:

      [[language]]
      #include <wire.h>#include <spi.h>#include <adafruit_lsm9ds0.h>#include <adafruit_sensor.h>#include <kalman.h>//Arduino Mega:
      //#define LSM9DS0_XM_CS 46
      //#define LSM9DS0_GYRO_CS 44
      //Adafruit_LSM9DS0 lsm = Adafruit_LSM9DS0(LSM9DS0_XM_CS, LSM9DS0_GYRO_CS);
      Adafruit_LSM9DS0 lsm = Adafruit_LSM9DS0();
      
      #define RESTRICT_PITCH
      Kalman kalmanX;
      Kalman kalmanY;
      
      // Create sensor events (these get "filled" with data)
      sensors_event_t accel, mag, gyro, temp;
      float accX;
      float accY;
      float accZ;
      float gyroX = 0;
      float gyroY = 0;
      float gyroZ = 0;
      int16_t tempRaw;
      
      float sRoll;
      float sPitch;
      int maxDev=10;
      float dev;
      
      float gyroXangle, gyroYangle;
      float compAngleX, compAngleY;
      float kalAngleX, kalAngleY;
      uint32_t timer;
      
      char AngType = 'R';
      float CompVal = 0.02;
      
      // Setup for Sensors
      void configureSensor()
      {
        lsm.setupAccel(lsm.LSM9DS0_ACCELRANGE_2G);
        lsm.setupMag(lsm.LSM9DS0_MAGGAIN_2GAUSS);
        lsm.setupGyro(lsm.LSM9DS0_GYROSCALE_245DPS);
      }
      
      void setup()
      {
        // Set SS to high and OUTPUT so a connected chip will be "deselected" by default
        //digitalWrite(53, HIGH);
        //pinMode(53, OUTPUT);
        Serial.begin(9600);
        Serial.println("Getting started");
        // Try to initialise and warn if we couldn't detect the chip
        if (!lsm.begin())
        {
          Serial.println("Oops ... unable to initialize the LSM9DS0\. Check your wiring!");
          while (1);
        }
        Serial.println("Found LSM9DS0 9DOF");
        Serial.println("");
        configureSensor;
      
        delay(100);
      
        lsm.getEvent(&accel, &mag, &gyro, &temp);
      
        accX = accel.acceleration.x;
        accY = accel.acceleration.y;
        accZ = accel.acceleration.z;
        gyroX = gyro.gyro.x;
        gyroY = gyro.gyro.y;
        gyroZ - gyro.gyro.z;
      
        #ifdef RESTRICT_PITCH // Eq. 25 and 26
          double roll  = atan2(accY, accZ) * RAD_TO_DEG;
          double pitch = atan(-accX / sqrt(accY * accY + accZ * accZ)) * RAD_TO_DEG;
        #else // Eq. 28 and 29
          double roll  = atan(accY / sqrt(accX * accX + accZ * accZ)) * RAD_TO_DEG;
          double pitch = atan2(-accX, accZ) * RAD_TO_DEG;
        #endif
      
        kalmanX.setAngle(roll); // Set starting angle
        kalmanY.setAngle(pitch);
        gyroXangle = roll;
        gyroYangle = pitch;
        compAngleX = roll;
        compAngleY = pitch;
      
        sRoll = roll;
        sPitch = pitch;
      
        timer = micros();
      }
      
      void loop(){
        lsm.getEvent(&accel, &mag, &gyro, &temp);
      
        accX = accel.acceleration.x;
        accY = accel.acceleration.y;
        accZ = accel.acceleration.z;
        gyroX = gyro.gyro.x;
        gyroY = gyro.gyro.y;
        gyroZ - gyro.gyro.z;
        double dt = (double)(micros() - timer) / 1000000; // Calculate delta time
        timer = micros();
      
        #ifdef RESTRICT_PITCH // Eq. 25 and 26
        double roll  = atan2(accY, accZ) * RAD_TO_DEG;
        double pitch = atan(-accX / sqrt(accY * accY + accZ * accZ)) * RAD_TO_DEG;
      #else // Eq. 28 and 29
        double roll  = atan(accY / sqrt(accX * accX + accZ * accZ)) * RAD_TO_DEG;
        double pitch = atan2(-accX, accZ) * RAD_TO_DEG;
      #endif
      
        double gyroXrate = gyroX / 131.0; // Convert to deg/s
        double gyroYrate = gyroY / 131.0; // Convert to deg/s
      
        #ifdef RESTRICT_PITCH
        // This fixes the transition problem when the accelerometer angle jumps between -180 and 180 degrees
        if ((roll < -90 && kalAngleX > 90) || (roll > 90 && kalAngleX < -90)) {
          kalmanX.setAngle(roll);
          compAngleX = roll;
          kalAngleX = roll;
          gyroXangle = roll;
        } else
          kalAngleX = kalmanX.getAngle(roll, gyroXrate, dt); // Calculate the angle using a Kalman filter
      
        if (abs(kalAngleX) > 90)
          gyroYrate = -gyroYrate; // Invert rate, so it fits the restriced accelerometer reading
        kalAngleY = kalmanY.getAngle(pitch, gyroYrate, dt);
      #else
        // This fixes the transition problem when the accelerometer angle jumps between -180 and 180 degrees
        if ((pitch < -90 && kalAngleY > 90) || (pitch > 90 && kalAngleY < -90)) {
          kalmanY.setAngle(pitch);
          compAngleY = pitch;
          kalAngleY = pitch;
          gyroYangle = pitch;
        } else
          kalAngleY = kalmanY.getAngle(pitch, gyroYrate, dt); // Calculate the angle using a Kalman filter
      
        if (abs(kalAngleY) > 90)
          gyroXrate = -gyroXrate; // Invert rate, so it fits the restriced accelerometer reading
        kalAngleX = kalmanX.getAngle(roll, gyroXrate, dt); // Calculate the angle using a Kalman filter
      #endif
      
        gyroXangle += gyroXrate * dt; // Calculate gyro angle without any filter
        gyroYangle += gyroYrate * dt;
        //gyroXangle += kalmanX.getRate() * dt; // Calculate gyro angle using the unbiased rate
        //gyroYangle += kalmanY.getRate() * dt;
      
        compAngleX = 0.93 * (compAngleX + gyroXrate * dt) + 0.07 * roll; // Calculate the angle using a Complimentary filter
        compAngleY = 0.93 * (compAngleY + gyroYrate * dt) + 0.07 * pitch;
      
        // Reset the gyro angle when it has drifted too much
        if (gyroXangle < -180 || gyroXangle > 180)
          gyroXangle = kalAngleX;
        if (gyroYangle < -180 || gyroYangle > 180)
          gyroYangle = kalAngleY;
      
        /* Print Data */
      #if 0 // Set to 1 to activate
        Serial.print(accX); Serial.print("\t");
        Serial.print(accY); Serial.print("\t");
        Serial.print(accZ); Serial.print("\t");
        Serial.print(gyroX); Serial.print("\t");
        Serial.print(gyroY); Serial.print("\t");
        Serial.print(gyroZ); Serial.print("\t");
        Serial.print("\t");
      #endif
      
      //  Serial.print(roll); Serial.print("\t");
      //  Serial.print(gyroXangle); Serial.print("\t");
      //  Serial.print(compAngleX); Serial.print("\t");
        Serial.print(kalAngleX); Serial.print("\t");
      
        //if((kalAngleX > (sRoll+maxDev))||(kalAngleX < (sRoll-maxDev))){
        //  this is your emergency stop
        //}else{
          dev = sRoll-kalAngleX;
          Serial.print(dev);
        //}
      
        Serial.print("\t\|\t");
      
      //  Serial.print(pitch); Serial.print("\t");
      //  Serial.print(gyroYangle); Serial.print("\t");
      //  Serial.print(compAngleY); Serial.print("\t");
        Serial.print(kalAngleY); Serial.print("\t");
      
        //if((kalAngleY > (sPitch+maxDev))||(kalAngleY < (sPitch-maxDev))){
        //  this is your emergency stop
        //}else{
          dev = sPitch-kalAngleY;
          Serial.print(dev);
        //}
      
      //#if 0 // Set to 1 to print the temperature
      //  Serial.print("\t");
      //  double temperature = (double)tempRaw / 340.0 + 36.53;
      //  Serial.print(temperature); Serial.print("\t");
      //#endif
      
        Serial.print("\r\n");
        delay(2);
      }</kalman.h></adafruit_sensor.h></adafruit_lsm9ds0.h></spi.h></wire.h> 
      
      posted in General Discussion
      kraegarundefined
      kraegar
    • RRF 3 / Duet 3 and 3 point Bed Tramming

      Board: Duet 3
      Firmware: RepRapFirmware for Duet 3 v0.5
      Printer: RailCore IIZL (3 independent leadscrews)

      Probing the bed and auto-tramming, the system never converges. It appears to over correct and vary the amount of tilt between two leadscrews. bed.g is 4 points and worked with RRF 2.x. on the same printer.

      The relevant bits of config.g:

      ; Axis and motor configuration
      M569 P0 S0 ; Drive 0 goes backwards X / Rear
      M569 P1 S0 ; Drive 1 goes backwards Y / Front
      M569 P2 S1 ; Drive 2 goes forwards Z Front Left
      M569 P3 S1 ; Drive 3 goes forwards Z Rear Left
      M569 P4 S1 ; Drive 4 goes forwards Z Right
      M569 P5 S1 ; Extruder
      M667 S1 ; corexy mode

      M584 X0 Y1 Z2:3:4 E5 ; Map X to driver 0, Y to driver 1, Z to drivers 2,3,4. E to driver 5

      ;Leadscrew locations
      M671 X-10:-10:283 Y22.5:227.5:125 S7.5 ; locations to pivot points, as measured

      ;BLTouch
      M558 P9 C"io8.in" H5 R1 F50 T6000 A5 S0.02 B1
      M950 S0 C"io8.out"
      G31 X2 Y42 Z2.64 P25 ;

      Bed.g:
      M561
      G30 P0 X10 Y43 Z-99999
      G30 P1 X10 Y228 Z-99999
      G30 P2 X195 Y228 Z-99999
      G30 P3 X195 Y43 Z-99999 S3

      Results:
      9/9/2019, 3:12:10 PM Leadscrew adjustments made: -1.884 0.116 0.002, points used 4, deviation before 1.043 after 0.011
      9/9/2019, 3:13:40 PM Leadscrew adjustments made: -1.844 0.153 -1.819, points used 4, deviation before 1.468 after 0.012
      9/9/2019, 3:15:50 PM Leadscrew adjustments made: -1.887 0.114 -0.045, points used 4, deviation before 1.048 after 0.011

      I tried going to 3 points in bed.g, and it gives similar results.

      I did notice that the first adjustment always says a negative number, but when it gets to the point where it applies the adjustments, I can visibly see the 3rd (right) lead turn but not the first (front left). No adjustment to that leadscrew actually happens. I'm not sure on the second, it may be that correction is just too small to detect.

      posted in Beta Firmware
      kraegarundefined
      kraegar

    Latest posts made by kraegar

    • RE: No output from G32 on DSF 1.2.4 / DWC 2.07

      @Danal said in No output from G32 on DSF 1.2.4 / DWC 2.07:

      Yay!! I'm still new with 3 motor beds, and it really helps to see the output. Yay!!

      I strongly recommend using a script to auto level until it's under a set value, with a Z home at the end. I've been doing that with one of my printers, and it's been awesome. The other day I had a bit of filament stuck right where my probe hits one spot, and so it couldn't level correctly. It failed to level under my set value, so I went to check and found the filament. Might have saved me a bed surface!

      posted in Duet Web Control
      kraegarundefined
      kraegar
    • RE: No output from G32 on DSF 1.2.4 / DWC 2.07

      @chrishamm said in No output from G32 on DSF 1.2.4 / DWC 2.07:

      Glad it's working now. The issue with G32 not showing any output should be fixed in DSF 1.3.1, too.

      Great news. I'll have to stop printing face shields long enough to upgrade and test!

      posted in Duet Web Control
      kraegarundefined
      kraegar
    • RE: No output from G32 on DSF 1.2.4 / DWC 2.07

      Tried in chrome just to verify (I usually use Firefox)

      33c932c4-a315-4b0e-b521-f69b4ccc57ac-image.png

      posted in Duet Web Control
      kraegarundefined
      kraegar
    • RE: No output from G32 on DSF 1.2.4 / DWC 2.07

      @Danal Man, I'm stumped.

      I had this reported by a user. I was running DWC 2.0.5 and DSF 1.2.3, and was getting output just fine. So we started troubleshooting. When I updated DSF to 1.2.4 (which upgraded DWC to 2.0.7) I "lost" the output on the console. Doesn't matter how I run it - I can hit the button in DWC, run G32 manually, or even run M98 P"bed.g" - I get no output for the adjustments made.

      Duet Web Control 2.0.7
      Board: Duet 3 MB6HC (MB6HC)
      DSF Version: 1.2.4.0
      Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-RC1 (2020-02-08b3)

      posted in Duet Web Control
      kraegarundefined
      kraegar
    • RE: No output from G32 on DSF 1.2.4 / DWC 2.07

      Just tried it, no change.

      posted in Duet Web Control
      kraegarundefined
      kraegar
    • No output from G32 on DSF 1.2.4 / DWC 2.07

      Upgraded from DSF 1.2.3 to 1.2.4 (which upgraded DWC from 2.05 to 2.07 as well), and running my bed.g no longer gives any output in DWC.

      RRF 3.0 on a duet3

      posted in Duet Web Control
      kraegarundefined
      kraegar
    • RE: RailCore (Core XY) + Duet 3 + Raspberry Pi + RRF 3.01-RC1

      I have a config for a RailCore II / Duet 3 / SBC that's compatible with 3.0 or 3.01 here:
      https://www.dropbox.com/sh/pg0ugu5qunokjc9/AAD8PkPqVGPp-yWV5Cug3_Usa?dl=0

      Some sample conditional gcode examples here: https://www.dropbox.com/sh/gb8v16bgmyzq78t/AABgqjcDaqf4cLirguvjDlFfa?dl=0

      posted in Firmware installation
      kraegarundefined
      kraegar
    • RE: RepRapFirmware 3.01-beta 3 released

      Been printing steadily and haven't seen any issues to report yet. Still tinkering with conditional gcode 🙂

      posted in Beta Firmware
      kraegarundefined
      kraegar
    • RE: RepRapFirmware 3.01beta1 released

      I couldn't get abs to work either, so just nested the if statements. Ugly, but I figured it was something I was doing wrong. Also testing on a duet2.

      posted in Beta Firmware
      kraegarundefined
      kraegar
    • RE: Auto-Tramming a RailCore Using conditional GCode

      @deckingman I wouldn't worry too much just yet...

      Now when variables arrive, then we're talking!

      posted in Gcode meta commands
      kraegarundefined
      kraegar