Pin Definitions & MA860H

[Mark Brown]

I'm looking to wire up to a MA860H and after reading the .h, I'm a bit confused.

Accel Stepper defaults to 2,3,4,5 unless you edit the .h file for different pins, or define new pins in the constructor from what I can see. However, it is not clear which pin is for what purpose....

The MA860H has Puls+ (+5V), Puls- (PUL), Dir+ (5V), & Dir- (DIR). How does the AccelStepper Library relate to these? 

    /// Defaults to AccelStepper::FULL4WIRE (4) pins.

    /// \param[in] pin1 Arduino digital pin number for motor pin 1. Defaults

    /// to pin 2. For a AccelStepper::DRIVER (interface==1), 

    /// this is the Step input to the driver. Low to high transition means to step)

    /// \param[in] pin2 Arduino digital pin number for motor pin 2. Defaults

    /// to pin 3. For a AccelStepper::DRIVER (interface==1), 

    /// this is the Direction input the driver. High means forward.

    /// \param[in] pin3 Arduino digital pin number for motor pin 3. Defaults

    /// to pin 4.

    /// \param[in] pin4 Arduino digital pin number for motor pin 4. Defaults

    /// to pin 5.

[gregor]

If you connect it like discribed here: http://www.leadshine.com/UploadFile/Down/MA860Hm.pdf figure 10, you should be able to use AccelStepper with the driver interface. If you don't, you will have to write your own step functions (very simple) and can still use AccelStepper.

[Mike McCauley]

You do t have to change any library files to get different pins. The .h just defines the defaults. You can set them to any pin you like by providing arguments to the constructor in the usual C++ way. 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "accelstepper" group.
To unsubscribe from this group and stop receiving emails from it, send an email to accelstepper...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hugh Gilhespie]

Hi Mark,

This code works for me - I am using a Leadshine MA542 driver that has the same pin functions.

// domerotateBig.ino

// Version 03 12 Aug 2015

// DOME ROTATION MOTOR CONTROL

// Uses AccelStepper (http://www.airspayce.com/mikem/arduino/AccelStepper/)

// This sketch is used on an Arduino Nano to generate the pulses, direction and enable signals required by the LEADSHINE MA542 stepper driver.

//

//INPUTS

// The 'proper' controller is an Arduino Mega. The Mega sets three lines which are read by the Nano to determine the action to be taken.

// The three Mega pins are read by the Nano on pins PD2 (2), PD3(3) and PD4 (4) so these are set as inputs. These three digital values are

// decoded to give 1 of 8 possible actionCommands.

// The values and corresponding actionCommands are:

// Pin 2 Pin 3 Pin 4 actionCommands

// 0 0 0 No Action

// 0 0 1 Rotate Clockwise

// 0 1 0 Rotate Anticlockwise

// 0 1 1 Graceful stop

// 1 0 0 Not yet assigned - defaults to Graceful stop

// 1 0 1 Not yet assigned - defaults to Graceful stop

// 1 1 0 Not yet assigned - defaults to Graceful stop

// 1 1 1 Emergency stop

//

//OUTPUTS

//The Arduino Nano provides the following digital outputs:

// direction signal to stepper driver Pin PB3 (11)

// pulse stream to stepper driver Pin PB4 (12)

// enable signal to stepper driver Pin PD1 (9)

// pulse stream to blackboard monitor Pin PD5 (5)

#include <AccelStepper.h>

//ACTION INPUT PINS

#define                actPin0 2             

#define                actPin1 3           

#define                actPin2 4 

//MA542 DRIVER PINS

#define                stepPin 12             

#define                dirPin 11             

#define                enaPin 9      

//CREATE INSTANCE OF STEPPER MOTOR

AccelStepper myMotor(AccelStepper::DRIVER, stepPin, dirPin, true);

//VARIABLE DECLARATIONS

int myAccel = 1;

int mySpeed;

long mySteps;

int myStatus;

boolean isMotorRunning = false;

long myCounter = 0;

boolean myStopflag = 0;

//TRIAL USING ACCELERATION EXAMPLE

void setup()

{ 

  //Set minimum pulse width (2.5 uS for MA542 driver)

  myMotor.setMinPulseWidth(10);

  //SET UP ENABLE PIN

   myMotor.setEnablePin(enaPin);

   

   // ENABLE is Active Low

   //Don't invert Direction and Step Pins, Invert Enable Pin

   myMotor.setPinsInverted(false,false,true);   

   

   myMotor.enableOutputs();

   

   myMotor.setMaxSpeed(937);

   //myMotor.setSpeed(979);   

myMotor.setAcceleration(100);   

myMotor.moveTo(110000);

}

void loop()

{  

   //myMotor.runSpeed();

   // If at the end of travel go to the other end

    if (myMotor.distanceToGo() == 0)

      myMotor.moveTo(-myMotor.currentPosition());

    myMotor.run();

}

Hope this helps,

Regards, Hugh

[Mark Brown]

Hugh, 

Thank you! Works like a charm. Nice truth table in your code too for device communication. I'm curious: have you already written the functions for graceful stop and emergency stop and the corresponding handler for pin states?

[Hugh Gilhespie]

Hi Mark,

Glad your sketch is working. The answer to your question is no. I have actually gone a different route and decided to use I2C comms rather than bit banging. My project is a controller for an amateur astronomical observatory based on a 2.2 metre dome with a separate shutter. The dome rotation and shutter opening will be controlled by several separate Arduino boards, three Nanos, one Uno with a Zigbee shield and one Mega. The Mega is the actual 'controller'. 

The reason for so many microcontrollers is that my programming skills are basically non-existent and it is MUCH easier to divide the various tasks such that each Arduino only does one simple thing - like drive a stepper motor. It also means that all the critical, time-dependent code is handled more easily amd the actual Mega controller doesn't have to do anything special. just bumble along polling the other micros and reacting accordingly. Anyway, having decided to use my (sort of) 5-core Arduino processor, I would have been too short of pins even using a Mega to go with bit banging, hence the I2C.

I am actually just finishing off the control box hardware, should finish it tomorrow, then the fun starts trying to programme everything!

Regards, Hugh

On 17 October 2015 at 08:36, Mark Brown <mark...@gmail.com> wrote:

Hugh, 

Thank you! Works like a charm. Nice truth table in your code too for device communication. I'm curious: have you already written the functions for graceful stop and emergency stop and the corresponding handler for pin states?

--

[Mark Brown]

Hugh, 

Very cool. Sounds like a neat project. If you've documented it, it might make a cool post on hackaday.

I also have gone with a I2C schema for communication between chips. It's a pretty convoluted setup using switch/case statements in the loop and the TxHandler on slave devices to set variables received in the RxHandler, but it works pretty nicely in my testing so far. I haven't found a need for anything more robust than 328ps on protoboards for master and slave devices. As it stands now, I'm looking at about 15 slaves, and opted for a Raspberry Pi running a java application to read command strings from a sqlite database, transmit to the master over serial at timed intervals, and write responses to a MySQL database. Still a lot of work to be done on charting the data with javascript. 

Curious, why did you choose the zigbee for wireless? I went with wi-fi on the Pi, as it was the less costly way with my setup, and my last experience with zigbee was a pain. That assessment is largely influenced by having to manage mesh networks of dataloggers which were in close proximity to each other. Setting Pan IDs became the bane of my existence, and surprisingly, a shared PanID from networks miles apart would occasionally pick up a datalogger that should have been a part of another network (I'm talking 10+ miles!, though they did have line of sight)

[Hugh Gilhespie]

Hi Mark,

Your project is at a whole different level to mine! I am still learning as I go along and I chose zigbee just because it seemed easy to use. I haven't tried to use it yet so I am still blissfully unaware of all the pitfalls I shall no doubt encounter.

We are right out in the sticks - way out - so I doubt there is any risk of cross-channel interference (famous last words?). All I need is to send two signals - open shutter and close shutter - across worst case 8 feet, so not a demanding task. I am slightly miffed that the zigbees plus shields plus programmer actually cost a lot more than I intended and I have now seen lots of other wireless transceiver boards for a small fraction of the zigbee cost. Still, they are in my 'to make' box now and I will give them a go.

My programming 'skills' are really not good. The only formal course I took was in Algol 60 which will give you a good guess at my advanced age. (And that was Algol 60 running on an ICL1903 with punched card input). Then Dartmouth Basic - an Open University state of the art system that used paper tape input and teletype output. Then a Nascom 1 micro and the joys of machine code for two years until I could afford to buy an 8k ram board and use a 'proper' assembler.

I moved on to do a bit of 80286 assembler under DOS and some VB6 and VBA then nothing for a good few years until I started playing with PIC's about 4 years ago. So, C, C++ etc are all new to me and I haven't got a clue about object oriented anything. Still good fun though albeit ultra frustrating at times.

Regards, Hugh

--

[Mark Brown]

Hugh,

Yea, Zigbee is definitely overkill for such a short distance and simple shutter release functionality . You might want to check out the esp8266. There are protoboard friendly models & something called the huzzah that would do that standalone, in a much smaller package.