1. Got a question or need help troubleshooting? Post to the troubleshooting forum or Search the forums!

Anyone use G2/G3 on RoBo?

Discussion in 'Software' started by Drmike, Apr 3, 2016.

  1. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    21,246
    Likes Received:
    7,011
    It is a marlin RC so bear in mind that new bugs you don't currently have may be included for free :)

    Definitely give it a try, just don't be surprised by any extras you get.
     
    Drmike likes this.
  2. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    I uploaded the RC5 version with the auto leveling and I used Octoprint to send the gcode and run it from the SD. The only difference I see from before at start is that it goes to the center of the bed instead of 0,0,0 - but all the gcode is executed correctly. All my circles are printed as expected, but a touch faster than I saw before. I also have some bugs in the gcode where it seems to be going over the same circles twice but without the whole thing running I'd never have known. It looks like I'm on my way to making great stuff with the RC5 (no bugs have bit me yet, other than my own!)

    Thanks Waldo, this looks very promising compared to what MatterControl was giving. Now I just have to fix my gcode generator.

    Dr. mike
     
    mark tomlinson likes this.
  3. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    21,246
    Likes Received:
    7,011
    One would hope (assuming a normal development cycle) that any RC version would be largely bug free and only unforeseen edge conditions should be problematic. However, given the rather fast-and-loose way they do some things it is not certain :)

    The good news is that there are a core of developers who do care about the product (or at a minimum their section of it).
     
  4. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    The whole environment is pretty complex though. You have the embedded code on the printer, you have the slicer engines, and you have the programs that send the slicer results to the embedded code. Each one of those is done by a different group, and they are all trying to be flexible for many printers. The code on the printer is the most critical, but so is the hardware. Again, those are two different groups. I am really happy that the Marlin code works well on the RoBo. For what I want to do, writing my own slicer is pretty easy, but I was not liking the idea of writing a control program. Thanks to this forum, I didn't have to.

    Clearly a lot of people have spent a lot of time making this environment work as well as it does, but there is only so much time in a day. There are a million ways to do the same task, and every one who tries will come up with a different solution. There's a fine line between dedicated and crazy - so I'll call everyone who works on this stuff dedicated. I'm definitely benefiting from all that effort. So:

    THANKS EVERYBODY! This is a blast! :)
    Dr. mike
     
  5. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    Well, I have really screwed things up now - I'm hoping somebody else has seen this kind of problem and can tell me what I did wrong.

    I tried the RC5 with Octoprint, and I finally got my gcode to look correct. But the Z axis seemed wrong so I decided to switch back to the standard 1.0.0 (ROBOV3). Now the left side z drive seems to randomly go up and down and the right side obeys commands correctly.
    After loading the original code, I issued the M502, M500 commands.

    What would cause one motor to misbehave if it just software?
    Dr. mike
    Edit: I swapped in the RC5 version just to check, one side works, one side doesn't. That does point to hardware since two different versions of software do the same thing. Time to dig under the cover and look for loose wires. I suspect I damaged something because I was dragging the nozzle on the bed for too long - although all the circles were perfect and in the right place so I was pretty happy about that!
     
    #25 Drmike, Apr 6, 2016
    Last edited: Apr 6, 2016
  6. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,806
    Likes Received:
    3,526
    Could be as simple as a loose connection.
     
  7. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    I think so - I took the bottom off, disconnected every plug to that motor and plugged them all back in (none felt loose) and now it works fine (with minicom).

    So the next question I have for you is that M851 command - is that just the negative of the M565, or does it do something else?

    I like it when things fix themselves for no known reason - I suspect one wire to a stepper had bad contact, and it was just coincidence with how I was running. Better if they don't break, but hey, some times shit happens!
    Dr. mike

    Edit: second question: what does M500 and M502 do if you power on and off a lot and don't sent those? That is, after loading the RC5, and powering off, does that really matter?
     
    #27 Drmike, Apr 7, 2016
    Last edited: Apr 7, 2016
  8. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    Oh man, what a trip! With Octoprint driving, my G2/G3 arcs and circles are perfect. The RC5 code drives correctly for both linear and arc motions - but I now need to play with height between moves and the order in which I do the lines in my layers. I am not very efficient, but I would not have known that without actually watching. I also have a few bugs to fix - the E value is wrong in one subroutine but the printer has no problem blasting out more volume than is needed. As we say in Wisconsin FORWARD!!
    Dr. mike
     
  9. WheresWaldo

    WheresWaldo Volunteer ( ͠° ͟ʖ ͡°)
    Staff Member

    Joined:
    Feb 18, 2015
    Messages:
    5,806
    Likes Received:
    3,526
    So many questions! :D

    M851 - it is the offset between when the Z axis probe hits the bed and when the Z-Axis endstop is actually hit. In our case, as a result of Robo using the extruder as the probe, the endstop switches activate after the probe its the top of the bed. Essentially Z0 comes below the top surface, so you need a positive offset to move it up. This makes much more sense than having M565 with a negative number and more negative meaning higher off the bed. Since Z0 is now below the bed, we need to offset that 0 location to make it the top of the bed. As we probe around the bed the offset is added to each point to insure that the nozzle is precisely at the bed when in location 0 and not trying to dig into it.

    M500, M502 - These are solely for EEPROM values. At startup Marlin reads the firmware and stores a bunch of values based on that in working memory. Immediately after that it reads what has been set in EEPROM and overwrites any values it finds that are different. If you stored any value in EEPROM those are then the ones it uses in working memory. Marlin does not run from EEPROM. There is an interesting side effect, although I am not sure why Marlin does this. When you flash a new firmware, Marlin does not appear clear out the EEPROM area, so old values may still be in effect. That is the reason for M502, which rereads the firmware and places those values back into working memory. Following that with an M500 command will store the working memory values back into the EEPROM area.

    EEPROM survives power disconnects, it won't matter if you disconnect every wire on your Arduino, it is there and it is semi-permanent storage. Robo did not enable EEPROM in any of their various versions of firmware (all based on Marlin 1.0.0). EEPROM comes in handy for things like MESH bed profile, Z axis offsets, and the like.

    Octoprint is even better if you run it on a small SBC like a Raspberry Pi Zero/2/3.
     
  10. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    If you can figure out a way to make your own slicer that is accurate about using G2/G3 appropriately when slicing, you'll get all kinds of Internet points with various hobby users for a slicer that generates files so much smaller than what other slicers generate.
     
  11. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    Thank you for that explanation! Totally makes sense, I am surprised the Arduino loader does not zero that out which is why I am glad I asked.
     
  12. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    Yes, I'm sure that's true! The problem is I wrote a very SPECIFIC gcode generator based on the mathematics of my shape - a hexagonal grid of circles held together with a set of bars. The STL->GCODE slicers could not handle my description, so I bypassed the problem.

    The problem is the source. STL converts the original description into triangles. You need to get that original description and use the arcs/circles to generate the gcode. I used BRLCAD, which is a solids modelling method. It has specific shapes which would be very easy to get the approximations to arcs from. I didn't need to do that - I wrote a script for BRLCAD based on the math, so it was just as easy to write C with the math going direct to gcode.

    I like embedded systems. The project of converting some specific file format (NOT STL) to gcode would be really big. I think somebody here said "programmers make lousy project managers" and I definitely resemble that remark :)
    Dr. mike
     
  13. daniel871

    daniel871 Well-Known Member

    Joined:
    Apr 18, 2015
    Messages:
    1,322
    Likes Received:
    510
    I was also thinking a native format like a STEP file or Binary Parasolid as the source for the slicer would be cooler. It's how the more intelligent CAM softwares do tool pathing for traditional CNC machines.
     
  14. Drmike

    Drmike Member

    Joined:
    Feb 9, 2016
    Messages:
    48
    Likes Received:
    11
    Absolutely. I had the chance to work for a year in a machine shop and the CNC tool path software was awesome. And that was 15 years ago. But they have armies of programmers and can afford to pay them :) We gotta take what we can get!
     
  15. mark tomlinson

    mark tomlinson ༼ つ ◕_ ◕ ༽つ
    Staff Member

    Joined:
    Feb 21, 2013
    Messages:
    21,246
    Likes Received:
    7,011
    Yes, that is true (and so is the flip-side)

    :)
     
    Drmike likes this.

Share This Page