No, not usually.
I’ve done several projects using Arduinos and more advanced microcontrollers. I’m really confused on what the issue is.
- Arduino uses libraries. The source for them is right there in the Arduino directory, and you can edit the source or study it to see how to define your own libraries. (it’s super simple, you just put your stuff into another source file and then #include it generally. There’s also a way to import additional libraries)
- You can easily divide your code into separate modules.
You are wanting run-time linkage? That’s not only a bad idea, I do not see a valid reason for this. It is possible in Windows but causes lots of problems there as well.
You do not need to use Eclipse and you shouldn’t waste your time with a niche tool in a complex environment like that. The basic Arduino IDE is good enough for your purposes and it actually works as is. It is possible to set the IDE write to almost any arduino compatible microcontroller.
I don’t remember what you are talking about with .h files, but you can just call them .c files and it will still work…
Arduino IDE + arduino is the closest thing to something that “just works” short of a game console…It’s been radically simplified to make this easier.
Your project is interesting in that there are several ways to draw any set of input figures, and each strategy involves more or less “unwanted lines”, where the etch-a-sketch leaves a line when it travels to draw an unconnected figure. It would be interesting to work out an algorithm to solve for the minimal amount of unwanted pixels. How does your feedback sensing system work?
Yeah, I know. But the basic Arduino IDE has a problem with files that don’t end in .ino, so I went looking for a different editor. This is now widely regarded as a bad move.
I haven’t even gotten as far as “Hello, World!” yet. The lines on the Etch-A-Sketch I’m using are pretty fine; can barely see them from more than an arm’s length. I figure that for any actual drawing or text I’ll use double (or more) lines and the single lines will look less significant. I’ve also read somewhere that there’s a technique to erase unwanted lines. As the stylus within the Etch-A-Sketch moves, it leaves a line but also erases a little bit on either side of the line. If the stylus moves in kind of a spiral motion, I might be able to get it to clean up after itself as it moves.
No feedback sensing yet. Not sure how I’d do that, or if I’ll need to. This will probably only be running when I’m around to watch it. If I see something going wrong, I’ll just pull the plug.
Do you have a rest position switch for the stepper motors? I missed the fact you were using steppers - some of my projects had to use other motor types and needed sensors.
I would suggest you represent the input data as vectors with stop and start points. Create the figures you wish to draw as vectors as well. Then, your solver just has to consider different orders of going to a given vector and drawing it that minimize the number of movements that don’t draw on a vector.
With vectors, your most primitive operation is a movement from (x1,y1) to (x2, y2). That’s what you want to implement in the arduino IDE. You can then put the code that does that in a separate C file if you wish. Then you would have code that retrieves vectors from stored data and feeds it as a series of point to point movement commands to the movement code…
Then you have code that retrieves the actual vector commands from a stream sent from your computer. Each piece builds on the others, but you want to test and debug thoroughly the bottom piece in your software stack, then do the same for the next piece up, etc.
There’s a way to convert a bitmap file back to a vector representation but I suspect the math is complex.
That’s kinda where I am right now. I’ve had it working in a test script with XY coordinates hard coded within the script. Trying to separate the drawing commands into a library is where it got interesting (in a bad way).
One thing that might make it hard to use code from a 3D printer is that there’s a lot of slack in an Etch-A-Sketch. When you change direction on either of the knobs, it takes several steps before the stylus starts moving again. So the code has to keep track of which way each motor last turned, and when that changes insert extra steps to take up the slack.
Why is there this slack? I’d remove that from the drive mechanism if you possibly can. That’s what you want feedback for - stepper mode step counts are probably not a direct correlation between clicks on the stepper and knob turns. You need feedback to know where the actual drawing stylus is I think.
Anyways, you do not need a “library” like you are thinking of - in the microcontroller world, a library is often just a callable C function that does the drawing. So it might be called Etch_Draw(x1,y1, x2, y2). You should stick all the dependencies for Etch_Draw inside the C file for Etch_Draw, and use ifndef, etc if you are concerned you might try to include some of these dependencies elsewhere.
More complex systems do have what you are talking about - a binary linkable file where you can link to prototypes in the header file, and those prototypes will call upon memory addresses in the binary file. But your project doesn’t need that kind of complexity, so why add it?
The whole reason the Arduino IDE is like it is is to make it minimalistic. As you probably know, the minimum program is just setup(){} and Loop(){}. The menu options are the minimum number needed to effectively develop simple programs. This makes it extremely nice for newer users - there’s not the massive, unfathomably vast section of menus and submenus that an environment like Visual Studio confronts you with. All those settings adds up to billions of ways you can set something wrong and not get anything to work…
Your project can be implemented with a simple program, by the way. Even if you need to implement solvers, there is not much to it.
I’d really rather not have to open up the Etch-A-Sketch and tighten up the mechanism if I don’t have to. In fact, the plan is to be able to slip one E-A-S into my rig, draw on it, and if I like the result, keep it. Then I can keep that one, give it away, whatever, and slip another E-A-S in and draw something else. I don’t want to have to tinker with each one to make it work.
I’m not trying to write a library that will link at runtime. I’m just trying to implement a class and save it in a file.
Yeah, and the Arduino IDE has been nice up to this point. But seriously, it can’t edit and save a .h file?
Put your physical drivers in the lowest level of software. That’s where you keep track of XY movement that has to be accounted for to change direction. So that level should be passed data representing the slope as a unit increment on either the X or Y axis and the number of increments on that axis. Check for changes in direction based on the changing signs of those values. Account for taking up slack when that direction changes. The slope and number of increments can be precompiled so your code has to do nothing but run through a list of those values. For arbitrary shapes you’ll want to decode a string of direction changes, those can be easily reduced to 2 bit codes. This is pretty simple for an etch-a-sketch because you just drawing one continuous line, however, you might want to work out a way to backtrack to a known point instead of encoding all the data to go back over a line.
That’s all stuff I’ve got figured out. I’m just trying to organize the code to best implement it.
It’s not enough to just track the slope to know when to take up the slack. If slope goes from positive to negative, I know one of the motors has changed direction, but not which one. And if both motors change direction, the sign of the slope will not change. But I do use the slope in controlling the motor steps; how many x steps go with how many y steps, and which one needs to step next.
You know, if you’re programming a computer to use an elaborate mechanical system to make drawings on a toy from the 1960s, you could just cut out the middle machine and make the drawings right on the computer.
It’s the signs of the slope components that change.
Anyway, now you have me interested. I’m going to download their software and order one of those little suckers.
I’ve done that. I wrote a Spirograph emulator when I was teaching myself C programming. That was in the early '90s. On my brother’s 386 machine, it was dog slow; a lot faster on a 486.
This current project isn’t so much for the end result, just an interesting way of teaching myself some microcontroller/motor controller/hardware stuff. And when it’s done I’m hoping to show off my mad skillz to prospective employers.
At the moment, my drawing function uses absolute coordinates. If you imagine the screen of the E-A-S to be an x,y coordinate plane (with the origin at wherever the stylus happens to be when the program starts), a call to drawTo(x,y) just draws a straight line from the stylus’s current position to x,y. I could do it relative, so drawToRel(0,100) draws up 100 steps from the current position.
Best of all, I could implement both and see which one turns out to be more convenient in the long run. But let me get over my current hurdle first.
This is rapidly becoming not a Pit thread.
It can. Just create your .h and .cpp files in the project directory (the one with the main .ino file in it). Load up your sketch and the files will automatically appear as new tabs. If your sketch is already loaded, close the IDE and relaunch it.
Alternately, you can go to Sketch->Add File and type in the filename you want, but note that this will only work if the file doesn’t already exist.
One thing about the Arduino IDE is that it doesn’t really like files outside of the project directory. If you add them, it’ll just copy them locally. The exception is packages that live in the main Arduino directory. You can add libraries here and use them across multiple projects, but it’s not easy to edit them as part of your project. Your best bet is to work on the library locally, and when you think it’s in a fully working state, copy it back to the Arduino dir to share it across other projects.
If your stepper motor is slipping, it’s not powerful enough for the application. The whole point to a stepper is that they can be used as an open loop system (no feedback). If you have feedback, you may as well use a non-stepper.
C lacks most of the features needed to do this the way you do it in fancier languages. Just write a function and stick it in a separate file. You missed what I said earlier - there is zero technical difference between .h and .c, so I guess the Arduino authors removed the meaningless bit of complexity and call everything .c.
Strangelove. Suppose knob 1 is turned enough to the right that the stylus on the etch-a-sketch is moving smoothly in the direction it controls. It takes exactly 35.3 steps to turn the knob to the left to start it moving the other way…or it is 35.4…
You see the problem? Without feedback and a loose drive mechanism, your knowledge about where the stylus is will rapidly degrade, degrading faster the more direction switches you perform. This is why the OP needs to either tighten up the drive mechanism or use feedback.
The 3d printers that use steppers have 2 things that make it practical :
- There’s a switch that tells the microcontroller when the print car is in a known position, such as the bottom, back, left side of the print cage.
- There is absolutely no slippage - the steppers have adequate torque that every step is completed successfully, and there is a hard metal gear drive system that moves in discrete increments.
I agree that tightening up the drive mechanism is good, but in principle this can be accounted for. Lower-end CNC milling machines have the same exact problem and it can be worked around. The mechanical solution is better but more expensive.
First of all, you always keep track of the stepper position. The only way to lose track is if the motor isn’t powerful enough for the job. This is always something you should account for–hence the limit switches–but it’s not something that should happen under normal conditions.
Accounting for the slop just means keeping track of the stylus position separately from the stepper position. Suppose the Etch a Sketch has 3 step units of slop. If you want to move the stylus to X=10 and the stepper is currently at 2, then you must move it to 13 for the stylus to be in the right place. If you want to draw a short line from 10 down to 9, then you must move the stepper to 6.
That’s a simple model, but probably good enough here. A more complex model might take speed into account, since the strings will probably stretch based on the velocity. Probably more effort than it’s worth.
Note that (given the simple model), you can never be all that far off with the stylus position–it’s always within 3 units of the stepper position (which, again, you can keep track of perfectly). And if you ever need to get the stylus position back exactly, you just start at X=6 and move to 0. The stylus will be guaranteed to be at X=3 at that point.
BTW, there is such a thing as “micro-stepping” where you basically interpolate between steps to get a higher effective resolution. However, the net behavior is basically the same as a normal stepper with the increased resolution. You still only lose steps if the stepper is inadequate.
No, it isn’t within 3 units of stepper position. Suppose the “slop” is, again, a non integer number of steps, and it’s a number you don’t know precisely. Every time you direction change, the unknown slop drives your position further and further from where you think it is. I just wrote some code today that has this problem, and the accuracy has no limit to how far it can degrade… The only way to reset it is to turn the knobs until they stop turning - your stylus is now in a known position. But, you need a sensor for this - some stepper motors have sense wires so you can detect the missed steps when you hit the limit of how far the knobs will turn.
Microstepping where you get more integer units would help a lot, sure. That might work well enough to draw basic figures.
Or, what I’m saying, you work out a sensing scheme. I don’t know how etch a sketch drive works. Variable resistor position sensors, a marker on the etch a sketch pin and a photo-diode - there are a lot of ways to do it.