Hi,
I'm looking for someone to write some code for controlling movement of stepper motors for a stapling machine I created a few years back. I have code that works and have been using it for a number of years but it has some quirks to it that are fine if I'm using the machine but if someone else jumps on it then I have to show them work arounds for the quirks.
What I really would like is someone with experience coding for equipment so i can see how they go about creating the code as to how I did, it took me quite a long time to piece the code I use and some things work great and other parts of the code get the job done by some stroke of luck.
I will attach my sketch, wiring schematic and I have a youtube video so you can see it in action. The movements are very simple and the motors bounce between hall sensors and they are controlled by another hall sensor doing counting.
Let me know what you think it will take to code a new sketch and cost you think is fair, you don't have to use mine I just added it for pin assignments and any other info you might glean from it.
I agree with zwieblum, the code is not so bad, but I do have problems with the hardware.
A footswitch with only the internal pullup resistor is not good enough.
The 330Ω might be too low, some pins can do only 4mA on the Arduino Due board.
I see no GND wiring in the picture, and the GND wiring is important.
Well, I think that ground bar (top left) must be connected to your 48V supply somehow, as there's no other return path for the step and direction signals. Other than that, I think the basic circuit would work, though there's no question a bit of 'industrial strength' signal interfacing would be desireable, else you'll likely see noise issues.
Those are your optical sensors across the top center? They're pulled up by the 330 ohms when not driving low, correct? 330 seems a bit extreme, but it's not the Due driving them, they're on inputs, so no big deal.
Does your touch screen need power? I suspect it's also fed from the 5V.
These are all reasons to suspect the schematic is incomplete, by the way. No offense, but getting these basics right will help you, and give whomever takes this on some confidence that the scope of work is known.
I thought my Wiring schematic was up to date but it's been a while since I made it.
I have the signal common from the stepper drivers going back to the Ground bar which is connected to the Arduino. The 48V isn't grounded to the Arduino, everything I read said don't send high voltages back to the Arduino so I didn't.
The sensors at the top are Hall sensors, they are powered by the Arduino 5V and are open drain. I started with a larger pullup resistor on them but had poor behavior from them and it was much better with the 330 ohm. The majority of the hall sensors were fine as they aren't near any of the steppers to suffer from interference but 1 sits on near the back of one stepper and counts revolutions and I would get phantom counts and the 330ohm resistor cured that, I still get a phantom count every now and then but it's tolerable.
The LCD is a shield that plugs into the top of the Arduino.
The code that I created has a few small problems,
The LCD screen buttons act fine but on startup I have to set one as active and in order for it to go off when another button is pressed I have to press it first and then try another button.
The rest of the problems have to do with the hall sensors controlling the movement. The homing code in the setup works fine for the carriage motor but on gantry motor it needs to run in 2 directions to home itself and one directions always works correctly but when it moves back to the other hall sensor it doesn't really go to the sensor. The motor will go back to where it started from on it's first move so if the gantry was moved while the motors are off then homing isn't correct.
I've tried different ways to make it work but my coding abilities are very limited and thought a more experienced person could clean things up.
One thing to consider is that depending on how extensive the changes you need will be, the developer may need access to the machine, or a similar one.
There are ways around this: I've used TeamViewer when the device I was working on couldn't be shipped due to weight & size limitations. Hard to ship an imaging machine that's big enough to scan a horse! In fact, I'm just now finishing up a project where we decided that the cost of TeamViewer for one month was less than the cost of shipping the machine to me and then back.
So bear that in mind. If all you need fixed is some button functionality, that may possibly be done remotely fairly easily, at the cost of efficiency since it's not easy to fix bugs on something you can't access.
