Hi, I've just built and coupled the ACRO 1515, and tested it with some hello world-programs, and I have to say I'm impressed! Super easy to build and use, so thank you! However, in a project I'm working on, I'm not going to use any toolhead-connection, but want to control the position, speed and acceleration from a PLC instead. My question is; how should I go forward for implementing this, is there an easy way to control the ACRO from a PLC, for example via ethernet? If there is any general documentation on the interface of the Blackbox, feel free to guide me there! PS: the PLC in question here is a Siemens Simatic ET 200SP. Thank you in advance, - Adrian
The grbl comms interface is detailed on the Grbl Wiki - see Grbl v1.1 Interface Same command/response set can be accessed over a Telnet interface if its the BlackBox X32. Both has a UART too: docs:blackbox-x32:aux-serial [OpenBuilds Documentation]
As I can understand by the Grbl Wiki, there is a "look ahead planner-buffer". Is this buffer something I can access? If I am not mistaken, when a G-code line is active, for example: [G1 F1000 X1000 Y1000], for example starting from pos (0,0), you cannot stop this command/movement without stopping the machine (M0) or doing a soft-reset? My idea then (because we want to change the trajectory as quickly as possible), is to never have more then 1 (or a few) commands in the buffer with very small changes in position. Then, based on a input, lets say "forward" og "backward", we either continuously give the buffer small steps to complete in the same direction as before, or change the direcetion and then give the buffer small steps in the new direction. My question really, is: can I access this said buffer, and does this seem like a possible solution? If not, I would highly appreciate any input or ideas! Thank you.
The buffer is internal. Check out the Jogging page of the wiki to see a method of short moves + cancel jog realtime commands
Thank you, this seems to be what I'm looking for! So if I have a joystick (or another speed- and direction-variable signal) and in worst case the speed-input changes constantly, with the direction changing periodically (like the motions of a pendulum), am I correct in asuming the jog would be replaced (the previous jog is cancelled with "!" (?)) with a new one (with a new speed) all the time? If the scenario is as following: The joystick ramps up the speed in a positive direction, then ramps the speed down until it changes direction and ramps the speed up in the negative direction. Which of the following implementations would work? : We continously set small position-changes (say +5mm) in the positive direction where we only change the feedrate, before we reach the change of direction, where we now set the position-changes (steps) as (-5mm), and continue to change the feedrate for each step. We set the position as maximum in the positive direction as we are ramping up, but cancel this jog for each feedrate-change, replacing it with a new jog with the new feedrate, but the same maximum position as reference-point. And when the direction changes we set the position-reference-point to maximum in the negative direction, and change the feedrate by replacing the jogs, as before. I'm a little confused to as if we need the updating of small steps (as initially thought), or if the position could just be set in a direction (maximum) so the only thing we think about is the feedrate. Sorry if this is implicit. I'm completely new to G-code and this way of thinking. Thank you.
That's how OpenBuilds CONTROL handles it. Sends a max distance move on keydown, sends the cancel command on keyup (fixed feed throughout the move though) If you need realtime feed, it will have to be short moves Trial and error best way to learn. Try multiple approaches
Thank you, that makes my problem so much easier What is the cancel command btw? I've tried " ! " and "0x85". If i insert $J=G90 G21 X100 F1000 in the Serial Console and then insert " ! ", I just get an "ok", but the jog doesnt stop. If I insert 0x85, I get an error instead, which says: error 9 - G-code locked out during alarm or jog state [0x85]. Is jog cancel not possible in the Serial Console perhaps?
Okay, i tried ASCII now, and wrote the horizontal ellipse (…), which is 0x85 = 133(dec), but it seems like it doesn't work. I don't get an error but an "ok", though it doesn't stop the jog. Should that not work? If so, why does it say "ok" and not do anything?
I'm sorry but could you give me a little more than that? Do you mean this: GitHub - OpenBuilds/OpenBuilds-CONTROL: OpenBuilds CONTROL: Download from https://software.openbuilds.com ? If so, where am I supposed to look? And does this mean that ( … ) should have worked and that i need to trubleshoot and fix something, or is the realtime-command simply wrong?
Well, a little, but we also can't write it all for you (; Frontend function: OpenBuilds-CONTROL/app/js/jog.js at f3c9b79ecdea7bac5a151a3fbd776d5272162c6d · OpenBuilds/OpenBuilds-CONTROL Backend code that handles the ascii send OpenBuilds-CONTROL/index.js at f3c9b79ecdea7bac5a151a3fbd776d5272162c6d · OpenBuilds/OpenBuilds-CONTROL Don't use the serial console, its syncronous. We wrapped the interface into our code, if you want to use CONTROL instead of the PLC, you can use JS macros and functions like cancelJog({data.jog: true}) But after all, you want to do that on the PLC side? Of course CONTROL prevents users interjecting realtime commands from the serial console for their own protection, its a purpose built UI of course, but when you write your own code, do it per the wiki Use CONTROL's source if you are wondering about how to implement some functionality, but we are just following the Wiki too
It seems kinda pointless to use a position, speed and acceleration controller that doesn't do what you actually want to do (because it's not designed to) vs either building your own interface on top of core grbl motion control functions (more or less hacking the buffer to support realtime control and get rid of g-code) or just building your own controller. What you actually seem to want is a robotic PID control with realtime inputs and maybe filtration, not really an asynchronous, planned motion controller for repeatable motion?
Yeah, I worked it out last night that the serial console was limiting my inputs, and especially realtime-commands. When using puTTY instead, the jog-cancel-command worked perfectly so I'm assuming it will work as wanted, when streaming the code (ASCII, not G-code right?) direcetly to the BlackBox X32. And again, thank you for all the help, its much appriciated Yes, thats correct. I was tasked with implementing the ACRO1515, and I'm supposed to control it from a PLC (Siemens). Or at least thats where I'll get my inputs from. I do agree. I'm just a summer intern assigned with a task, and the ACRO was decided and ordered long before I arrived. Though I have to say the ACRO seems absolutely perfect for what its designed for. Im tempted to get my own at home actually.
Well, both, and also "$" commands. But yes. Grbl's comms are quite simple, for the most part, most of the work of a UI is to prevent the user from doing bad things. One thing that might be hard to implement on the PLC is the queue (Grbl wiki offers two, ping pong or character count)
