Thanks for the reply, I appreciate it. So the hardware is already complete and works very well indeed. I can move motors about, using the examples in the IDE.
I'm prepared for a steep learning curve, just need someone to show me where the curve is, so I can straighten it out.
Arduinos are programmed in C++, so some time reading the early chapters of a language tutorial would be helpful.
On the other hand, if you don't intend to use an Arduino again any time soon,you may be able to cobble something together using the example code in the IDE that will get quite a long way.
Do you have limit switches to allow you to home the steppers?
Thanks for the reply and thanks for the advice. Yes limit switches have been installed. These are just basic micro switches, with pull down resistors.
As for control, there are pots to control speed, the idea being, once a limit switch is pressed, the motor reverses, until the other limit switch is pressed. As I understand it, using 2 switches in this way, they could both be connected to the same pin.
I don't see a need for it to home on start up, or for it to count steps, just 2 limit switches on each axis and 1 pot for each axis.
As you’re certainly on the first step of what can becomea lengthy journey, you need to ask yourself
“Do I want to spend a good part of my life developing a new skill set, or do I just want to solve ‘this’ problem?”
If it’s the first, you need to put.on your big-boy pants, and settle in for a rewarding bumpy ride… or it’s the latter, a trip online to buy a packaged solution will be faster,nand let you continue with the rest of your life.
I think you are combining two different processes into the idea of "coding skills". There are coding skills and there are logically designing a program. You are here on the forum because of the latter, but are asking questions about the first.
The media and most other folks only talk about coding, which is writing computer code to accomplish what someone else designed and wrote down on paper.
Unfortunately, on this forum, both are combined into one and people try to code something that they have not, yet, written down on paper or their in their mind. The two things cannot be combined.
You need to first design your program and then when you are sure of the logic, you can begin to code the program. Look up flow charting on the internet. That is the best way to get your logic ready for coding.
Good luck,
Paul
When you are designing functional software, start with a detailed specification of what the software is supposed to do (not how it will do it). Then start designing a block diagram of the software from the top down. In other words, start with a few broad functional blocks, e.g. operator interface, data input, data processing, output functions, etc. Then break each block down one level at a time by splitting it into more detailed functions. Include flow and timing diagrams as needed. Continue to add more detailed levels until you can not simplify each one any more. At each level, define the inputs and outputs of each function. If you have existing libraries of some of the functions, e.g. standard interfaces, etc, include them in the diagram at the appropriate levels.
When you start writing the code, do it from the bottom up. Take each bottom level block and write a function that will do what is required. make each function independent of all of the others, defining the inputs and outputs. Test each bottom level function independently using real inputs or dummy data. When you have all the bottom levels written and tested, start on the next level up, incorporating the lower levels and make sure that they work together and do not interfere with each other. When you get to the top levels you will have tested, well documented code.
[image]
Last edited: May 4, 2021
-fab
P.S. Robin2 has some nice tutorials in "Introductory Tutorials" on this site as well. They too touch on software design, but in a pseudo code way.
...and there are others as well! From how to setup to using WiFi! See Introductory Tutorials...
+1 for that. Also, if you obey the spirit and maintain the integrity of the structured approach, you can forego certain things like flowcharts, etc. so long as you are genuinely following the approach. I rarely make charts or block diagrams etc., but I do make overview diagrams with notes, and detailed drawings/notes for areas with special problems or aspects. Sometimes I do not write code bottom up exactly, rather top down with "stubs" in some cases because the entire architecture must be vertically integrated and the "distance" between the top and bottom is great.
However, I have a lot of experience and often a project begins with a cup of coffee and just leaning back in the chair for a few minutes, thinking about the entire problem. I've found that to be surprisingly effective.
That is in contrast with leaping to the keyboard and creating code in the hopes that it will stimulate some enlightenment. That rarely happens, instead it usually results in becoming locked into a flawed or sub optimal solution.
No. If the algorithm is simple enough to make a comprehensible flowchart, you don't need one. If it's not, no stinkin' flowchart will do you any good.
In my experience, professional programmers whiteboard boxes and arrows, but those boxes are systems - a database or micro service or API provider perhaps.