Compatibility with mechaduino?

[TMECHA]

What is the compatibility with mechaduino? In particular the NEMA23 version?
Thanks in advance.

[misfittech]

The NEMA 17 can run the mechaduino firmware, the NEMA 23 has s different driver chip and thus can not run the Mechaduino firmware. 

Is there a feature in the Mechaduino firmware that the smart steppers are missing? 

thanks

Trampas

[misfittech]

I should mention that the Smart Steppers hardware has more features than the Mechaduino.  Including:

1. LCD and push buttons, if you want to configure without a computer

2. Buck power supply such that board can be powered from motor voltage 

3. Power Switch on the encoder to fix encoder lockups which have been seen to happen

4. 6- level shifted pins for (step, dir, enable, error, RX and TX) but can be reconfigured in firmware to be what you need. 

5. Better numeric stability (removed floating point errors in the firmware)  

Currently the only feature the smart stepper is missing is some of the features Kai has added to the Mechaduino firmware, including GUI and self tuning. 

[Michael Ross]

The mechaduino firmware allows for a RAMPS to communicate using i2c to change the mechaduinos to "torque mode" and to request state information.  How can this be accomplished with NZS firmware?

[misfittech]

There is several methods people have used.

1. There is the RX/TX pins which are TTL UART pins. You can use these and have all the commands on USB available. 

2. There is an option to have the step and direction pins change to UART when enable pin is not-enabled. This runs at 19200 baud. 

3. Some have removed LCD and used the I2C pins from the LCD to communicate, you need to add custom firmware for this. 

The first two options are controlled by #defines in the board.h and require you to rebuild firmware. 

I did the second option, changing step/dir to UART, as that it is simple to bit bang a UART at 19200 and that way you do not need to run extra wires. However everyone has their own needs. 

[Michael Ross]

Those are good options.  For us, we are hoping to use this as a drop-in replacement for mechaduinos in a "Hang Printer".  Looks like I would need to use step 3, by modifying the firmware, or modifying the Marlin FW that is currently being developed to communicate with the mechaduinos over i2c.

[misfittech]

Do you happen to have the specs or the firmware for the I2C I could look and see how difficult it would be. 

[Torbjörn Ludvigsen]

Hi I'm woring on making Smart Steppers a drop in replacement that can work with Hangprinter.

The code is here:

https://gitlab.com/tobben/Smart-Stepper-for-Hangprinter

I went for route 3 (removing LCD, using SDA/SCL like I do with the Mechaduinos). I bumped into the same issue as Phei describes here:

https://groups.google.com/forum/#!searchin/smart-stepper/i2c|sort:date/smart-stepper/Zo1p-Wjt7SU/ZqXyWTszBAAJ

The i2c communication will work for 1-10 messages and then hang.

Looking at debug output from the Smart Stepper, we end up with the error bit on the encoder constantly set:

https://gitlab.com/tobben/Smart-Stepper-for-Hangprinter/blob/82be0cb4e0a6245f7636db0488fd7d850637cef3/firmware/stepper_nano_zero/as5047d.cpp#L215

I can only provoke the bug if the i2c command does a call to sampleAngle() somewhere. In my test code I call only sampleAngle(), enclosed in enter/exitCriticalSection().

I have tried

 - waiting a few milliseconds inside readEncoderAnglePipeLineRead()

 - increasing t0 to 100, so readEncoderAnglePipeLineRead() will make 100 attempts at SPI-transferring valid data

 - resetting the encoder by calling begin() on it

None of the above have made any difference. The SPI link, or the encoder itself seem to sometimes get completely trashed when used within the i2c callback.

2.5.0.0

[Torbjörn Ludvigsen]

Like Phei, I can still query encoder values via i2c after the bug has occurred, and get correct values back. However, the feedback loop stops and the serial interface becomes unresponsive.

2.5.0.0

[Torbjörn Ludvigsen]

Removing all encoder readings from within i2c onRequest and onReceive handlers fixed the issue.

Here's the commit that fixes it:

https://gitlab.com/tobben/Smart-Stepper-for-Hangprinter/commit/4d296668e11170089cbb9fd477c03788c4c5b3a0

My current understanding of the issue goes something like this:

Reading the encoder requires SPI communication, which relies on using interrupts for timing.

However, as long as the i2c interrupt handler is running, the whole interrupt system is shut down/paused.

This sometimes works ok, the SPI interrupt just executes normally once i2c handler exits.

But there's a third interrupt that wants to be handled, the USB/UART.

If some code tries to call the UART (for example an ERROR or LOG statement) before i2c handler exits, then we're trapped in a nested interrupt that will never exit.

This shuts down both UART and the TC5 (motor control) operation.

Error and log statements are more likely to happen than usual when we're trying to read encoder over SPI while interrupts are paused...

The i2c keeps working because the processor is able to pause an i2c interrupt with another i2c interrupt.

2.5.0.0

[Torbjörn Ludvigsen]

Made interrupt handler even faster and more careful with which variables it touches.

Will stop spamming this old thread now.

Just wanted @Michael Ross and other followers of this thread that it works now:

https://gitlab.com/tobben/Smart-Stepper-for-Hangprinter

Best regards,

2.5.0.0

[misfittech]

Thanks for your work! 

[Michael Ross]

Ha!  I see it now!  ;)  I will go try this.

[Torbjörn Ludvigsen]

=)

Notice the new i2cid command. You can upload the same firmware to all Smart Stepper boards, and then set i2c address afterwards via serial :)

https://gitlab.com/tobben/Smart-Stepper-for-Hangprinter/blob/e3836b59a31f4ca58b05bbea0294ac4f0b675327/firmware/stepper_nano_zero/commands.cpp#L58

2.5.0.0

[Michael Ross]

That’s a great feature! Oops, is my geek showing?

Thanks for taking the time on this.

[Michael Ross]

When I compile this on for my smart stepper and access the serial monitor via USB through arduino, I simply get the message "You need to Calibrate" over and over.  It is not allowing me to send the "calibrate" command (or "help" or "menu" for that matter).  Am I missing something?

[Torbjörn Ludvigsen]

Oh, sorry about that. I also had that problem and fixed it, but it seems that I forgot to commit and push the fix.

Pushed it now (commit here). Try to pull and see if it solves the problem.

2.5.0.0

[Michael Ross]

That works much better. Thanks.

[Zakaria el HOuba]

Hello!

I am trying to get this code running but I dont even get past the Verify button (i.e. I havent even had a chance to try to upload it).

It gives me all sorts of "not declared in this scope" errors.

this far i got all these rendered unknown by the system: Serial5, PORT, intiateReset, and previously some more.

I tried compiling with different version of arduino IDE starting from 1.8.0 all the way to 2.0 and.. no surprise... no difference there.

can anyone please suggest what im doing wrong? is there some library I should have? or perhaps there is a bug?

I also tried with original code from misfitstech's github and got the same report..

thanks

michal

On Wednesday, 17 October 2018 at 14:15:52 UTC+2 Michael Ross wrote:

That works much better. Thanks.

[Trampas Stern]

Did you setup and install the Nano Zero see:

https://misfittech.net/blog/arduino-package-install/

--
You received this message because you are subscribed to the Google Groups "Smart Stepper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-steppe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/smart-stepper/3a14a621-cc8f-4e97-bbac-1bf777a9d759n%40googlegroups.com.

[Zakaria el HOuba]

Hello and thanks for the swift reply.

I have had nano zero available as a board but i realised taht misfittech board was not installed. so i updated the Arduino SAMD M0 Boards library to its latest relase and also installed the misfittech board. now i managed to comply and upload the code to the mechaduino.

thanks!

I do have another issue though. I have not been able to connect to the hardware over serial port. i am on macOs so i cant use putty. I have tried "screen" command over terminal but it can't connect to the board. i have than looked around and found this commercial software called Serial2. it does connect to the board but i cannot send any commands to it.

it says:

Power Up
:>Appears that there is no Motor Power
Connect motor power!

Of course, 12v power is connected to the terminals.

I eventually figured I could do the same over arduino IDE (didnt work out perviously) but i got the same message.

is there a procedure specific to mechaduino that i am not aware of when establishing a communication? any clues on why do i get that no power message? do i need to connect certain specific pins? i also tried pushing the button once/twice/long/not at all, but no effect there..

Thanks

[Zakaria el HOuba]

Ok.. things got worse

I moved the motor manually and now I get "you need to calibrate" message every single second.

I do understand that, but whatever i write into the serial it makes no difference. I am assuming it is stuck in a warning loop? how do i unstuck it?

thanks

(also the mechaduino has no display so i cant use any of the outofthebox options unfortunately..)

[Zakaria el HOuba]

Just a note - I tried this with the unmodified smartstepper firmware (ie not the one from misfittech github) and got myself into same situation with motor power.

[Trampas Stern]

It has been awhile since I have done anything with the mechaduino, so I am not totally sure about your errors.  However the motor power warning in later versions of smart stepper firmware is based on a voltage measurement of the motor power.  Mechaduino does not have this capability so as I recall it is determining if the board has power by trying to move the motor and seeing if the encoder shows it moved.  
This explains why when you manually move the motor the message changes.  My guess is that your motor is wired wrong to the board or you might have accidentally fried the motor driver chip.  The motor driver chip can be fried on the mechaduino if you disconnect the motor while the unit is powered on.  

Note it could also be a problem in the firmware, again I do not know if anyone has checked mechaduino compatibility in several years. 

Trampas

To view this discussion on the web visit https://groups.google.com/d/msgid/smart-stepper/7d1c97f0-a79c-49d7-b6a7-901f69b69ea1n%40googlegroups.com.

[Zakaria el HOuba]

Hello Trampas

Thanks for your reply.

I can confirm the motors are not fried. I tried on another one with the same result.

i used the firmware that is 3 years old and confirmed to work on mechaduino as well as the most up to date firmware from your github. both getting stuck on motor power message

I looked at the schematics of how i may connect the motor from your pdf manual. it seems that only matters that the two coils are connected next to each other on the board, which i checked with the ohm meter, and they are. the connection for the motor only goes one way into the terminal, so if there is anything miswired there, i would have to pull the cables out of its terminal case and rewire them.... is that what i should do? if so how?

Im attaching the image of my motors. its standard nema17 from ali.

bests

michal

--

- --- - - - - -- - - 

michalmitro.com

conceptual practice

[Trampas Stern]

My manual covers the smart stepper not the mechaduino hardware.  So its connection could be different on Mechaduino, as such you need to consult their manual. 

Also the motor most likely is not fried but the "motor driver" IC chip (A4954) could be fried.  This is what can be fried when disconnecting the motor with power applied. 

Trampas

[Zakaria el HOuba]

Hello Trampas

The motors work just fine with mechaduino firmware on them so I believe the hardware is intact. Also I have not been disconnecting the motor while board was powered, so that really shouldnt be the case.

Either way, you're suggesting that i get this no motor power message because the motor pins are not wired correctly, or there could be a different reason to that? I would assume, since the motor cables come bundled with particular standard routing, that the connection is correct. this is what i read in mechaduino manual:

When wiring your motor up to the Mechaduino board, please make sure that one phase is connected to outputs 1&2, and the other phase is connected to outputs 3&4.

That to me sounds like it is the same as for nano-zero. Would it matter if the phases are connected in these two ways? that's the only thing i may want to try (if that doesn't fry it potentially?)

pins:   1 2 3 4:

phase: a+ a- b+ b-

phase: a- a+ b- b+

the cables come bundled in specific combination to make sure that the phases are actually next to each other anyways. so the only meaningful thing to try would be to turn that connection around 180degrees.

would that solve it, you reckon? or  would that fry the motor?

Thank you

Michal

[Zakaria el HOuba]

thanks trampas

it seems this way goes nowhere. someone would probably have to dig into the code to make mechaduinos capable of hosting your nanostepper firmware. 

mechaduinos also seem to be discontinued so I guess I ll just go with step sticks... 

thanks anyway

michal

[Trampas Stern]

Misfittech.net sells boards that work with the Smart stepper firmware.

[Zakaria el HOuba]

I know. but I don't want to throw another 200bucks at this printer plus I need it ready kinda soon. but Thanks!!