Hey guys, I'm interested in the Acro sysem. My goal is to have the head position itself at a random xy location, and then move to another random xy location within the working area at a random speed. What would be the best way to do this? Please excuse my ignorance, but would it be possible to somehow have the system be driven by a raspberry pi to continually move to random locations until it is turned off or runs for a set amount of time?
Should be pretty straightforward as long as you're comfortable with some beginner-intermediate programming. Generate three random numbers with the Python random.randrange(start, stop, step). I'd separate it into a function which you can pass your travel limits, or your speed range. You'd generate it from a for loop, which would run until your timer flag hits. You'd pass say, "0, 1000, 0.2" for X, "0, 1000, 0.2" for Y, and "25, 800, 5" for your travel speed. You'd then have another function which you could pass the returned random values and it would format them into a G-Code string like "G1 X25.8 Y67.4 F615". Take that as a returned string value and pass that into another function which would send it over serial to an Arduino (or whatever ATmega-based box) running grbl, and then wait for grbl's "ok" response message before returning the program to the main loop, so you're not constantly generating random moves and overflowing grbl's serial buffer. Fairly straightforward. If you want it to be totally-self-contained, write the program in C for an Arduino with some basic motion control algorithm instead. The Pi/grbl approach just allows flexibility and extensibility. Either way, the larger picture is similar.
I would start with an RPi + GRBL based controller and use a standard GUI to make sure it all works correctly. Then I would grab gnea/grbl script and modify it to generate the Gcode for the random positions.
I thought about that too, but I think it insinuates a level of speed and asynchronicity that just doesn't apply here. There's really no need to keep recalculating buffer levels if you only need it to do one move at a time and forward planning is irrelevant. The lines are only about 20-30 chars long and only one executes at a time. Getting into "if (space in the buffer to calculate another line) then (go through the move generator again)" territory seems to be adding program complexity with zero difference in final result. Depends what else the Pi is doing at the same time as well, I suppose. In some circumstances where it's periodically resource-limited, banking additional lines could be useful.
I linked to the simple-stream,py script that does not do any buffer calculations at all, it sends a line and waits for a reply. I don't know where you got a buffer from?
Oh, the simple-stream script was linked to by the main documentation page when discussing buffer calculations to optimize motion planning efficiency. A simple-stream type script would be required in basically any execution but you phrased it as a further extension, so I thought that's also what you were referring to. Now that my brain is actually catching the word "GUI", I see that you're talking about steps 0 and 1 while I'm talking about steps 1 and 2. I had just assumed that "step 0: test and calibrate grbl with a GUI" would take place during machine construction, and wasn't within the scope of the question. This is what I get for replying BEFORE coffee! As you were, then.
Hey guys, thank you both for the quick replies. Would I still need to purchase the blackbox motion control system and the meanwell power supply? Or is the RPi + GRBL based controller a replacement for that stuff?
The stepper motors still need drivers and a power supply in order to actually move. Whether you provide those separately (I'm partial to these if you're cheaping out: https://smile.amazon.com/gp/product/B077MDVTF9) or getting an integrated solution like BlackBox (basically an Arduino and some drivers in a box, but pretty and with nice pre-built IO sockets), you'll still need a 24V power supply.
