a few months ago I build my own cnc machine including interpreter, 3d software
exporter and desktop controllsoftware.
Unfortunately I experienced that the older the desktop machine the cnc runs slower.
Between each command there is a short lag. I think that my code for my serial connection
is the problem but Im not sure.
Have a look here:
In short: my machine sends an "R#" when it is ready to recieve a command (in standby
or when the machine reached the desired location). My desktop software on the
other hand reads the "R#" and sends the next command that is in the stack and
does not send a new command until a new "R#" is read on the serial bus.
I thought about building an array of commands (maybe 5 commands) that act as
a buffer on the arduino but Im not sure if this will fix the lag between the commands?
Is there anything else I can optimize ?
Because the code is very large I upladed the full file of my Processing code
as well as the arduino code. -> Ive not included the gui classes for the processing
sketch.
To improve performance you should always try to buffer commands. I have not looked at the code but does processing calculate the next step, waits for arduino to request it, sends it and then calculate the next step, so on and so on? Ideally processing should be working one or more commands ahead and buffering them for another thread to feed to the arduino as needed and ideally the arduino would also buffer at least a command ahead so as it's executing one command the next is being sent. When you start buffering though you also need to think on how the arduino can react to critical command that may come out of sequence like an un-programmed emergency pause/stop command. This could be done with switches connected directly to arduino pins of maybe your happy to just kill power if stuff goes wrong.
It seems likely that your current method of asking for a command only when you've completed the last is responsible for your lag. Having said that, the fact that slower PCs make it worse suggests that there's work going on in addition to the serial piece. I haven't looked at the processing code - does it generate G-code on the fly? If so you might want to consider pre-building it and buffering the whole thing on the PC.
If that's not enough, buffering on the arduino could help too. One way would be to adjust your R# command to include a number of instructions you're prepared to accept. Ask for ten initially; when you've processed five, ask for another five. Try to ensure that your processing of serial happens in downtime while the CAD rig is doing something else.
Using Strings is not recommended - it's almost certainly not the cause of your issue, but it may cause you trouble down the road - stick to arrays of char.
That's a substantial lag, tens of millions of instructions on the PC, substantial
processing is happening (generating the GCODE on the fly would account for that
perhaps).
Definitely you want to buffer (normally a serial connection gives you that anyway
with flow-control?
Another possibility is that you are not generating the GCODE fast enough anyway
(seems unlikely).
And lastly you are using the maximum baud rate of course?
The g-code is not calculated on runtime it precalculated as a string and
passed to the arduino. So no cpu time for the calculation.
Yep I use a baudrate of 115200.
I think I will try to buffer a few commands in an array on the arduino side
to get a smooth motor control! Hope I get the logic to do so... unfortunately
there is no "push" and "pop" of arrays what would make life a lot easier...
@Riva: Good point on the saftey issue when buffering Riva! I will think of this a bit
what I can do!
@wildbill: hmmm I really had a hard time to get along with "chars" so I did it with
strings but I often read that one should stick with chars... I should learn to cope with
them.
