Re-Arm, any experiences?

Hi,

according to the kickstarter page the Re-Arm will be avialable for pre order soon, so Im wondering if someone already has used one and wants to share some experiences?

Cheers

Mine is trapped in customs! almost here.

But some discussions on the board are in these forums.

a few things I have seen of note:

1) its has no status leds, unlike actual smoothie boards but these can easily be added see [forums.reprap.org]
2) is only supports the lcd mentioned. (im sure this will be extended in time) but for now 20x4 char lcds are not directly supported, also the mks tft28 is not supported. I read that someone just plugged in, not surprisingly it fried the re-arm (5v on a 3.3v device).
3) At this time it only runs smoothieware. For me this is a positive. Marlin and repeteir are such old fashioned bloatware. Time for something newer.
4) The documentation is a little lacking, This should improve with time. Eg exactly which pins are 5v tolerant?

Some documentation here which isn’t linked from the main website (as far as I have found) [panucattdevices.freshdesk.com]

intersting points, Im actually looking forward to smoothieware especially working mesh level for deltas

Quote
sungod3k
intersting points, Im actually looking forward to smoothieware especially working mesh level for deltas

Don't all the major firmwares have working mesh level for deltas?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Not really. Marlin have what they call bi-linear bed levelling in RC8 but the whole firmware is just not optimised for deltas. I went back to Rich Cattell's testing fork of marlin on my microdelta as I was unable to enter enough calibration parameters from your calculator to get a good solution on Marlin, it will do endstops, radius, rod length and per rod trim but no tower position correction, radius error or tilt. Using RC's version and manually calibrating with the calculator I now have 0.02mm deviation. And the irony is this firmware which hasn't been updated in 15 months had grid levelling, which I can't use as I'm not using a probe and I don't need to as my bed is only 100mm diameter on this printer.

I think repetier can do it.

Edited 1 time(s). Last edit at 02/05/2017 04:58PM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Yes marlin is on it, but so far I cant get my 300mm bed under full control with marlin autolevel.

I'd heard before that Marlin wasn't very good for deltas (and experienced that myself two years ago), but I thought the recent releases might have improved things.

FWIW RepRapFirmware has mesh bed levelling for all supported printer types, and you can view the height map in 3D in the web interface.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
dc42

FWIW RepRapFirmware has mesh bed levelling for all supported printer types, and you can view the height map in 3D in the web interface.

Does RepRap Firmware work on a Re-Arm?

Quote
nebbian
Does RepRap Firmware work on a Re-Arm?

No, but that wont stop dc42 from his self promotion of his firmware on every single post.

From what I understand of if his firmware, it probably could be ported. Just needs a new abstraction layer

[OT]

Quote

Does RepRap Firmware work on a Re-Arm?

I'd go for RADDS then...

I was wondering why so many 32bit controllers adapt to smoothieware? Are there so many other forums out there, where it is popular?
Is RRF limited to users in this Forum?

[/OT]

There isnt that much choice I guess, RRF is specifically used in Duets, although im just seeing that it works with radds now as well. Smoothie is the only other real alternative to that I have heard of so far.

We can discuss the level of promotion and its appropriateness all day, but RRF/duet is a good system, and development is active and responsive to the users.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Quote
o_lampe
I was wondering why so many 32bit controllers adapt to smoothieware? Are there so many other forums out there, where it is popular?
Is RRF limited to users in this Forum?

By "so many" I think you mean 4 5 (Smoothieboard, 2 variants of Azteeg X5, MKS SBase and now Re-Arm) from 3 manufacturers, unless there are others that I am not aware of. Whereas RepRapFirmware runs on 3 versions of the Duet (soon to be 4), RADDS, and possibly the DUE3DOM MINI soon.

You will find both RepRapFimware and Smoothieware discussed in a number of other forums including:

[groups.google.com]
[forum.seemecnc.com]
[forum.e3d-online.com] (not sure I have seen Smoothieware mentioned in that one)

The Smoothieware section here is quite recent and not very active, because support is mostly done through [groups.google.com] and [forum.smoothieware.org]. Support for RepRapFirmware used to be done exclusively in this forum, but is now split between [www.duet3d.com] and the Duet, Ormerod and Controllers sections here.

Edited 1 time(s). Last edit at 02/06/2017 09:32AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

not to mention Azteeg X5 GT and Azteeg X5 mini, granted they are all related to the Azteeg X5. But if you can mention the 3 Duet variants, we can list these variants.

I shouldn't have asked, don't want to start a flame war here To late to delete my comment above

So let's stop here and go back to topic, please

I am waiting on my re-arm and partially this will be a test bed for some sensors I'm developing, I would like to have a machine with smoothieware for testing purposes, and just academic curiosity - I'd like to try that environment, although I am very pleased with RRF and if it could be ported to smoothieware style boards, I'd use it there too.

Is that possible David? I understand that the goodness of RRF is a tool to sell Duet boards, but how about a paid for port to smoothie-type boards, I'd probably pay for it.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Quote
Dust
not to mention Azteeg X5 GT and Azteeg X5 mini, granted they are all related to the Azteeg X5. But if you can mention the 3 Duet variants, we can list these variants.

I'm sorry, I didn't know there were two variants of the Azteeg X5. I've corrected that post.

Quote
DjDemonD
... although I am very pleased with RRF and if it could be ported to smoothieware style boards, I'd use it there too.

Is that possible David? I understand that the goodness of RRF is a tool to sell Duet boards, but how about a paid for port to smoothie-type boards, I'd probably pay for it.

I don't regard RRF as a tool to sell Duet boards, although it's true that the only reason I can devote so much time to developing and supporting RRF is because of the revenue I receive from Duet WiFi sales. Recently I have integrated support for RADDS in my source code tree and done RADDS releases too, although I rely on other people to test them. I am in discussions with two other people about helping them port RRF to their boards.

In answer to your question, there are some obstacles to porting RRF to the current generation of Smoothie-type boards:

1. Some parts of the hardware abstraction layer (CoreNG) use component files from the Atmel Software Framework. So porting RRF to other ATSAM-based boards is straightforward, but those parts would have to be rewritten for the non-Atmel processors used on Smoothie-type boards.

2. The current Smoothie-type boards (including ReArm) provide only 64K of RAM, compared to 96K on Duet085 and RADDS, and 128K on Duet WiFi. The IP stack we use (LWIP) works very well and supports multiple connections, but it uses a substantial amount of RAM. I doubt that we could make everything fit in 64K without making too many compromises. I don't want to get into the situation where you can only have one feature if you compile with another feature disabled, because having a single binary distribution for RRF with all features included is easier for users.

3. The current Smoothie-type boards don't support high speed transfers to the SD card, so we wouldn't get high speed file upload through the web interface.

Smoothieboard 2 is supposed to address #2 and #3, so porting RRF to Smoothieboard should be more practical in future. However, with the RAM constraint removed, Smoothieware on Smoothieboard 2 may catch up in the areas where it lags behind RRF, so there may be less incentive to do a port.

Edited 1 time(s). Last edit at 02/06/2017 09:32AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thank you that does explain a lot. I apologise if I caused offence by suggesting RRF is only a tool to sell Duetwifi boards. I can see the ram constraint being a big problem. Might there be a way to use the sd card as a ramdrive to get around it, or does the lack of high speed transfer just make this imppractical?

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Quote
DjDemonD
Thank you that does explain a lot. I apologise if I caused offence by suggesting RRF is only a tool to sell Duetwifi boards. I can see the ram constraint being a big problem. Might there be a way to use the sd card as a ramdrive to get around it, or does the lack of high speed transfer just make this imppractical?

No offence taken. I don't think the RAM drive idea would be practical. It's possible that RRF could be made to work in 64K RAM e.g. if we removed Telnet and FTP support, reduced the number of HTTP sessions supported to 1, reduced the number of supported drives to 5, and reduced the number of mesh bed levelling points. If you or anyone else wants to try doing a port, I'll gladly provide advice and support. But personally, I am more interested in porting RRF to other Cortex M4 processors and to Cortex M7.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

That would be way beyond me.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Re-arm boards are now available for pre-order:

[www.panucatt.com]

I just ordered mine! Looking forward to some of that sweet 32 bit action

Rearm plus tmc2100 should be awesome.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Quote
DjDemonD
Rearm plus tmc2100 should be awesome.

TMC2100 already run well with Mega/Ramps. But I only use them on X- and Y axis. The Prusa Y axis has shown missing steps or overtemp protection when Vref is wrong. There is only a small window, where I got it working.
Z-steppers won't run in series connection and running them parallel is beyond drivers current capabilities.
Extruder? Don't even try running a direct drive...

I like my RAPS128 better. Rock solid, silent and the steppers were never colder even at full current.

I wondered about this as I've been trying TMC2100s on x and y axes on my corexy and getting layer shifts occasionally, I turned them up (maybe down would be better). I'm running 0.9deg 48mm 1.68A steppers which are getting up to about 50 deg C. Drivers have a 40mm fan blowing straight down onto them. They were at 1.2v I've lowered them to 1.0v. I can't seem to make them skip by grabbing the carriage and putting some resistance on it, I let go fearing that it would break something before it skipped so what you said makes sense that it isn't too little current causing the skipping but something else.

This might be best continued on this thread about TMC2100 - [forums.reprap.org]

Edited 3 time(s). Last edit at 02/08/2017 02:53PM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Mine arrived today! Looks good. I'm going to have to get a graphic LCD to attach to it, apparently it doesn't support 4x20 line LCD panels.

Also in the order were some of the panucutt SD6128 drivers. I think that these should work quite well. 128 real microsteps! Feel the power!

I think I need to build another printer to put this in.

Yeah the graphical Lcd is quite underutilised, they don't even show two extruders and a bed temp on one screen it alternates between screens despite having no shortage of pixels. But it works.

Raps drivers might help? Still though at 128 microstepping that's still going to give the processor a thrashing.

The print quality though is a big improvement, I wasn't expecting it. My corexy is so, so compared to my kossel XL, but its turning out some really nice prints now without any mechanical changes.

Edited 2 time(s). Last edit at 03/03/2017 11:45AM by DjDemonD.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

Mine is coming tomorrow. I got it almost entirely for improved print quality at speed. My CoreXY print speed is being held back by the ramps board, and really chokes on fast curves. I'm hoping the 32 bit power will help out.

I'm quite sure you'll be impressed. If you havent used smoothie before its a bit different but the print quality is worth a day or two of adjustment to the new firmware.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions

I haven't used Smoothie at all before, just Marlin. I've already setup the Smoothie build environment. The only big issue I think I'm going to run into is my Z axis is currently setup with two motors on two separate drivers with two endstop, using the Marlin configuration that enables each Z motor to home to its own endstop. It doesn't look like Smoothie supports this currently, and digging through the firmware, I'm not sure I want to go through the effort to implement it right now. I think for now I'm going to strap a belt between the two Z motors to keep them synced, then move them both to the same driver. Eventually I'll probably want to eliminate that second motor entirely, but one step at a time.

I'm really excited for the board to come though.

Sounds like a plan.

---

Simon Khoury

Co-founder of [www.precisionpiezo.co.uk] Accurate, repeatable, versatile Z-Probes
Published:Inventions