Archim v0.3b

[[email protected]]

I remember a video of a Max running this control, what firmware did you use? I just ordered one. I was going to upgrade to a Duet wifi but I like the new hot end and probe and decided to wait for this control.

[Xenocrates]

I can find next to nothing about this controller. I have found evidence it uses a Due compatible branch of the Marlin firmware, which means it is unlikely to work the the HE280. I know that it existed enough to test in February, but also that Ultimachine does not sell it directly. It does not list I2C as an external communication protocol and I can't find a connector for it on the picture I have, which further puts compatibility in doubt. However, it could possibly run the Reprap firmware, if a version was customized for it's pin layout, although that is quite difficult as we have next to no information about that.

As an alternative, Mhackney was working on a little board to talk to the HE280 and give a simple endstop like signal, which would work with the Archim, Duet, or any other controller with any configuration.

It's not a very useful response, so I'm sorry if you're disappointed. But it's all I got.

[[email protected]]

I contacted ultimaker and got on a list to get a beta version. They did send me an email and it is using marlin FW, but I am hoping this will be the choice that seeme will use in the future since they posted a video of a max v3 running this board.

[626Pilot]

it is using marlin FW

Trust me, if you are running a Duet board, you do not want Marlin. You want RRF-dc42. Marlin's delta calibration is not as good as RRF's.

[[email protected]]

I am using the original Rambo board because I installed the new hotend from Seeme and at the time it is what would work with the accelo probing.
I think I will sell this board and use a Duet wifi with Mhackney's hack. I love the probing stuff DC42 has with his latest update. The graphic representation is very cool, cannot wait to get it working when I get home.

[adarcher]

I remember a video of a Max running this control, what firmware did you use? I just ordered one. I was going to upgrade to a Duet wifi but I like the new hot end and probe and decided to wait for this control.

Could you point me to where this video is? Sounds interesting at least.

[[email protected]]

[dc42]

... I was going to upgrade to a Duet wifi but I like the new hot end and probe and decided to wait for this control.

If you mean the accelerometer probe, this is working with the Duet WiFi but you need an adapter board. I have been working with Michael Hackney to get the accelerometer probe working really well with the Duet WiFi. One of the tricks seems to be to increase microstepping to 128x so that you can increase the accelerometer sensitivity to get more consistent results - and currently only the Duet WiFi offers 128x microstepping. I expect Michael will publish something on this soon.

[adarcher]

... I was going to upgrade to a Duet wifi but I like the new hot end and probe and decided to wait for this control.

If you mean the accelerometer probe, this is working with the Duet WiFi but you need an adapter board. I have been working with Michael Hackney to get the accelerometer probe working really well with the Duet WiFi. One of the tricks seems to be to increase microstepping to 128x so that you can increase the accelerometer sensitivity to get more consistent results - and currently only the Duet WiFi offers 128x microstepping. I expect Michael will publish something on this soon.

Hah, I was just thinking the same thing (about the microstepping) and am looking into getting a duet-wifi as well to test out some things.

I've got a different i2c accelerometer and have got it working with high temps as well, but it's always off by just a smidge from what I want it to be--consistent but off.

Can you switch microstepping modes on the fly with the duet-wifi?

(here I am derailing a thread when I hate when others do...)

Awesome! Thanks, didn't even think to see if there was a Facebook page... I only use Facebook to organize board games and log into other sites

[Xenocrates]

... I was going to upgrade to a Duet wifi but I like the new hot end and probe and decided to wait for this control.

If you mean the accelerometer probe, this is working with the Duet WiFi but you need an adapter board. I have been working with Michael Hackney to get the accelerometer probe working really well with the Duet WiFi. One of the tricks seems to be to increase microstepping to 128x so that you can increase the accelerometer sensitivity to get more consistent results - and currently only the Duet WiFi offers 128x microstepping. I expect Michael will publish something on this soon.

Hah, I was just thinking the same thing (about the microstepping) and am looking into getting a duet-wifi as well to test out some things.

I've got a different i2c accelerometer and have got it working with high temps as well, but it's always off by just a smidge from what I want it to be--consistent but off.

Can you switch microstepping modes on the fly with the duet-wifi?

(here I am derailing a thread when I hate when others do...)

Awesome! Thanks, didn't even think to see if there was a Facebook page... I only use Facebook to organize board games and log into other sites

Considering the microstepping is set via G-code, I would believe so. At worst, you may need to insert it into a different macro to call from the program, if it protects those from changing while running a print (DC42 is the only one who could help with that answer).

I would say this thread is rather derailed since the questions were resolved, and there's not a whole lot more information about the Archim to go over, since it's very thin on the ground.

[dc42]

I've got a different i2c accelerometer and have got it working with high temps as well, but it's always off by just a smidge from what I want it to be--consistent but off.

Can you switch microstepping modes on the fly with the duet-wifi?

Yes. Currently you have to re-home the printer when you change microstepping. In the bed.g file that controls auto calibration, it's usual to home at the start anyway. So you can increase microstepping before that. Then at the end of bed.g, set microstepping back to normal and home again.

[dc42]

Getting back to the topic of the Archim v0.3b. I am biased of course as I am the co-designer of the Duet WiFi. But anyway, here is my take on the Archim 0.3b from an engineer's point of view.

Good points:

Lots of protection against mis-wiring (as on the RAMBO):
- The thermistor and endstop inputs are protected (as on the Duet WiFi, and to a lesser extent on the Duet 085)
- There is TVS diode protection for the SD card socket
- There is both flyback diode and TVS diode protection for the heater/bed/fan output connections
- The USB connector is digitally isolated, which avoids problems with ground loops when you use a USB connection
- There are capacitors and Schottky diodes on the stepper motor output pins, which I presume is to try to protect the driver chips from motor disconnection under load. If this does add significant protection, it is good to have. I plan to test something similar with the Duet WiFi, with a view to including it on the third-generation Duet if it proves to be effective.

Bad points:

- No networking. How can anyone design a 32-bit board without networking? Duet and Smoothieboard had networking 3 years ago. You could use an external device to provide add-on networking, but without a high speed interface to the CPU you won't get a good speed when uploading gcode files. So networking needs to be integrated. The SAM3X8E processor has built-in Ethernet support, so why didn't they use it, like the older Duets do?
- The ATSAM3X8E is an old processor as ARM processors go. It was a good choice 3+ years ago when the original Duet was designed, but it now costs more than the ARM 4 processor that we use on the Duet WiFi - which is faster, has hardware floating point, and more RAM.
- The heater mosfets are poorly chosen. They are intended for 10V gate drive but only driven with 5V. So although the datasheet for the mosfet quotes a low Rds(on), that's only guaranteed at 10V gate drive. The Rds(on) at 5V could be anything. In practice most boards are likely to work OK, but in a large production batch there may be some boards with bed heater mosfets that get very hot under a heavy load. Designing for reliability in production is not the same as hacking together a one-off or a few prototypes.
- Only runs Marlin. Until there is a separate source tree for 32-bit Marlin that no longer tries to accommodate the limitations of 8-bit processors, Marlin will never be a good choice for 32-bit processors. OTOH the Archim uses an ATSAM processor, so it would be quite easy to port RepRapFirmware to it - although without networking you lose one of the major benefits of RRF.
- DRV8825 drivers, which are known for their issues when used with low-inductance motors (and low-inductance motors give the highest movement speeds). Best avoided unless the electronics is only intended for use with a particular combination of stepper motors and supply voltage.

Questionable design decisions:

- The TVS diodes they use for input protection are all bidirectional ones that will tolerate +/- 3.3V and clamp at +/-5 to 7V. Why didn't they use unidirectional TVS diodes? They would provide better protection against negative-going transients.

- All the mosfets are driven using fast mosfet gate drivers and low-value gate series resistors. Why? This is not only unnecessary at the low switching frequencies used in 3D printers, it increases EMI and causes larger transients due to circuit inductance when the mosfets turn off. Between the Duet 0.6 and 0.8.5, the mosfet turn off time was deliberately increased to control the inductive spikes and EMI.

- The TVS diode protection for the mosfet and fan outputs probably won't do anything useful, because the flyback diode and mosfet body diodes already provide good protection. If Ultimaker has any evidence that they do provide useful protection, I would love to see it.

[adarcher]

I've got a different i2c accelerometer and have got it working with high temps as well, but it's always off by just a smidge from what I want it to be--consistent but off.

Can you switch microstepping modes on the fly with the duet-wifi?

Yes. Currently you have to re-home the printer when you change microstepping. In the bed.g file that controls auto calibration, it's usual to home at the start anyway. So you can increase microstepping before that. Then at the end of bed.g, set microstepping back to normal and home again.

Makes sense. Can't be sure how the steps go when it switches...

Thanks for all the insight! I'm working on my own little controller board as a slow project to fool around with. It's nice to hear explanations for design choices. Especially for open source ones that don't have a lot of easily found open discussions for people who just getting interested.

[[email protected]]

Going with the duet wifi over the Archim v0.3, pm if you want to buy one for a reasonable price.

[johnnyr]

Hi, it's Johnny from UltiMachine. Just got pointed to this thread. Thanks for your interest in our board. We have put a lot of work into it. We just finished our EMC testing and will be ready for retail in March!

I see you already went elsewhere, but thought I should address the points brought up here.

Networking - We are working on daughter board options for wired and wireless networking. We did not default install ethernet because many people do not need it and it would be wasteful. This way you chose the connection method you prefer.

Processor -For Archim, we made sure we had adequate processor and memory, then we focussed reducing the risks of transition for printers to 32bit. We tried to maintain as much software and mechanical compatibility as possible. Tons of EMC work for various configs. Reliability testing. Etc. We can and will use other processors, but this one first. There is also decent Arduino support for this processor.

Heater Mosfets - The mosfet's rdson is plotted in data sheet down to 4.5V. It is thoroughly qualified and we get a good price since it is the same part we have been using on RAMBo.

Runs Marlin - Marlin is pretty much a pre-requisite for us to make a RAMBo upgrade. It makes migration easier and other firmwares are an option. Archim will run Marlin, TinyG G2, ReprapFirmware, or Repetier. Marlin with Arduino library compatibility is a goal since it has helped so many technological innovations from non programmers with RAMPS and RAMBo.

DRV8825 - The DRV does not have an issue with low inductance motors, when properly configured, unless they are driven with too high a voltage.

Bidirectional TVS diodes - This is good feedback. I appreciate it.

Fet Drivers - The gate resistor values were placeholders and were changed after we tuned the turn on time. The fet driver circuit is an inexpensive way to get sufficient voltage and current to turn on the FETs. The are overkill, but have a small footprint and are cheap due to being used in volume for other applications.

Fet TVS - The tvs diodes on the FETs are there during development in case we need them. We have not been able to blow the fets with 25kV ESD simulations though.

[dc42]

Thanks for responding. I disagree with most of your arguments, but I've already made the points I wanted to, so I won't repeat them. However regarding this one:

>> Heater Mosfets - The mosfet's rdson is plotted in data sheet down to 4.5V. It is thoroughly qualified and we get a good price since it is the same part we have been using on RAMBo. <<

You've made the mistake of confusing typical characteristics (which is what the plot shows) with worst-case characteristics. All this proves is that a typical mosfet of that type will work in your design. To see why this is not a safe assumption to make, look at the gate voltage at which the mosfet just starts to conduct in the plot of typical data. This is the typical gate threshold voltage. Now look at the figures given for gate threshold voltage in the data table. The value given in the "typical" column will match the value shown in the data plot. Now look at how much worse the value in the "maximum" column is.

The variation in gate threshold voltage is why the manufacturer does not quote Rds(on) at 5V or lower.