jcchurch13 / mechaduino-hardware Goto Github PK

Joe,

Apologies for opening a github issue, but I couldn't find an email address for you. I'm writing an article for opensource.com on some of the best open source hardware innovations in 3d printing in 2016, and I want to feature the Mechaduino. Would you be able to point me to a picture of the Mechaduino (maybe the "banana" picture from the kickstarter page) that I could use under a Creative Commons license (CC-BY-SA would be ideal)?

Thanks in advance,

Tom Callaway [email protected]

There are multiple places that I'm seeing a 10k pullup on the RESET line:

https://cdn.sparkfun.com/datasheets/Dev/Arduino/Boards/sparkfun-samd21-mini-breakout-v10.pdf

http://www.atmel.com/Images/Atmel-42181-SAM-D21_Datasheet.pdf -- Page 1022 under 39.4. External Reset Circuit

But on the schematic and board, R6 is listed as a 330ohm. This is a pretty strong pullup, is there a reason for the deviation?

From what I can understand of the firmware, and from looking at the schematic, you are missing out on field / vector control of the motor. With vector control you control the torquing current and the "magnetizing current" (think of the current that is 90 degrees out of phase with the torquing current). This allows for a few things:

• Easy "current advance" and it's more general cousin "field weakening" which is advance past the point needed for just overcoming inductance. It allows a much higher top speed when torque is allowed to decline.
• Better position accuracy (and lower position latency) by combining the encoder with the driving currents and a motor model through a Kalman filter. This especially would help here with the 50 pole motor.
• Some amount of force feedback
• Quieter and cooler operation through sine-drive commutation over square wave. I can't tell exactly what you have implemented now from a quick look at the firmware, so this one might not count.

The reason I bring this up in the hardware project is that you are missing motor feedback that is needed to allow this. The "normal" way to do vector control is to control the phase drive voltages (via PWM) and sense the phase currents. To do that you would need to add an amplifier to bias and scale the current sense resistors, and ADCs (maybe in the MCU already? I didn't look) that can sample at least around 40 per pole, or 2000 times per rotation on a 1.8 degree stepper.

Another option that may be possible (I'm making this one up as I go along, I don't know if it's been done before or disproven)... Since you are using a bridge driver that self-regulates current, I think it might be possible to implement vector control using a "control the current, read the phase voltage via PWM transitions" model. This would depend on being able to change the current Vref values at at least a few times per pole to control the phase current directly, and having some digital feedback from the motor phase outputs to know when the A4954 switches between internal PWM modes. This method would only need a diode or two and some resistors for each of the 4 motor leads. The big sticking point would be whether the A4954 Vref input has that kind of frequency response. I don't see anything to give a hint in the datasheet, so it might have to be determined by experiment.

Either of these methods would allow estimating the back-emf of the motor, which gives an estimate of motor position, and when combined with knowing the phase voltage or current give force feedback and the ability to directly control the 2 current vectors occurring in the motor.

Looking forward to getting some hardware... I'm glad someone is finally doing this!

Hi,
Why don't you add these diodes https://github.com/watterott/SilentStepStick/blob/master/hardware/StepStick-Protector_v11.jpg directly on your board? I think it would help a lot the printing quality.

Any word of advice on interfacing trinamic drivers on board instead of the a4954 stepper drivers? This so stepper operation can be quieter.

Hello All

Apologies for asking a question that may seem trivial, but I haven't been able to find an answer here or in the forks I was able to examine.

I was hoping to be able to use the serial interface, but over normal serial pins rather than USB. Are any of the existing pins available on the board attached to a serial peripheral? I realise I'll probably have to write up the serial handling myself, and happy to give that a shot, but in case there is another project that has done the same I'd be happy to take a pointer to such a project :)

can you share a gerber file for the v0.2 ?

Hey there.

Great project.

Both the hardware and firmware repos are missing a license file as far as I can see.
Once that's fixed and you confirmed it really is Open-Source, if you want we can send you a free Smoothieboard to use/test with your system.

Cheers.

After opening the firmware Mechaduino_01.ino in Arduino IDE 1.8.2, verification fails with errors from gcc. I tried to google things up, nothing shows up. Maybe some problem between keyboard and chair. I am new to mechaduino so maybe I am missing something obvious. I looks as if types were not recognized, but there is no error about #include not being found. These are the first few messages. Thanks for help!

sketch/analogFastWrite.c: In function 'syncADC':
analogFastWrite.c:17: error: invalid type argument of '->' (have 'uint16_t')
   while (ADC->STATUS.bit.SYNCBUSY == 1)
             ^
sketch/analogFastWrite.c: In function 'syncDAC':
analogFastWrite.c:24: error: 'DAC' undeclared (first use in this function)
   while (DAC->STATUS.bit.SYNCBUSY == 1)
          ^
sketch/analogFastWrite.c:24:10: note: each undeclared identifier is reported only once for each function it appears in
sketch/analogFastWrite.c: At top level:
analogFastWrite.c:29: error: unknown type name 'Tc'
 static __inline__ void syncTC_8(Tc* TCx) __attribute__((always_inline, unused));
                                 ^
analogFastWrite.c:30: error: unknown type name 'Tc'
 static void syncTC_8(Tc* TCx) {

Hey.

As part of the Smoothieboard v2 hardware design, we are planning a very complete series of "extension boards" : goo.gl/XP5iZc
Those boards will all use the "Gadgeteer" socket. It is small, it's a very nice and well designed standards, a lot of boars already exist for it. We also hope to encourage other Open-Source controller board designers ( running Smoothie or otherwise ) to also use these in their hardware.
If you were to add a Gadgeteer port to your board, that'd make it super easy to interface will all of the Smoothieboard v2 hardware boards ( and possibly other boards in the future ).
What do you think ? Maybe for a v2 of your hardware ...

Cheers.

BOM Line 31 shows 3.3V regulator AP2112K-3.3 as the value however the specified device is AP2202-ADJ.

The AP2202-ADJ needs additional circuitry on pin 4 to set the correct output voltage.

Perhaps update the BOM to reflect the correct device?

1 AP2112K-3.3               AP2202-ADJ                             SOT23-5@1                     IC2

Found this mistake while reflowing my boards; caused me to get a digikey order slightly wrong.

I was checking over the Datasheet for the AS5047D Magnetic Rotary Position Encoder

The section on power management has two configurations. One for 5V operation and the other for 3.3V operation.

For 3.3V operation it states -> "In 3.3V operation, VDD and VREG must be tied together."

In Figure 10 the "3.3 Operation" diagram shows VDD and VDD3V3 tied together with one 100nF cap to ground.

It would seem to me that C17 1uF should be removed from this circuit and pins 11 and 12 of the AS5047D should be tied together.

This could easily be fixed on the current board by a small bridge between C16 and C17 on the top of the board after removing C17.

PS I also reported this to the Mechaduino Google Group

What would be required to make this work with larger stepper motors like NEMA 34 etc.?