[Grbl_Esp32 Issue#17] (USG) DRO updating is sluggish

#1 – bdring 于 2018-08-06

Are you using the latest master branch of the code?

I noticed sluggish performance in responding to the “?” command due to the fact that the reading the serial is not interrupt driven. I changed that in the most recent version. See this closed issue.

I’ll give UGS a try and see if I get the same issues.

#2 – bdring 于 2018-08-07

I tried UGS and I am seeing sluggish DRO’s also. I have a serial port spy program, but unfortunately I cannot get UGS to run on that computer. It does not like my Java version, even after I reinstalled it.

Using that spy program, all other senders I use, appear to work fine. Grbl responds to all “?” commands right away. For some reason, UGS might not be sending the “?” marks all the time. It might be some other incorrect status item or response that causes UGS to pause.

#3 – misan 于 2018-08-07

Position polling should not interfere with data transmission.

If a lot of short lines or short arcs are to be transmitted, I won’t be
surprised most of the transmission time is devoted to g-code transmission.
Doing the opposite and transmitting lots of “?” will give a better path
tracking at the expense of creating pauses during the machining as planner
buffer may be empty ocassionally.

Different g-code senders may have a different sending policy and thus be
showing a different behavior. I would assume pauses are due to an excess of
“?” polls.

That said, I have done no tests with a serial port sniffer.

On Tue, Aug 7, 2018 at 4:17 AM, bdring wrote:

> I tried UGS and I am seeing sluggish DRO’s also. I have a serial port spy
> program <http://www.aggsoft.com/serial-port-monitor.htm>, but
> unfortunately I cannot get UGS to run on that computer. It does not like my
> Java version, even after I reinstalled it.
>
> Using that spy program, all other senders I use, appear to work fine. Grbl
> responds to all “?” commands right away. For some reason, UGS might not be
> sending the “?” marks all the time. It might be some other incorrect status
> item or response that causes UGS to pause.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/bdring/Grbl_Esp32/issues/17#issuecomment-410910893>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAccyOLfnKI_dmWfSWS9fTjSgDO6ZsBhks5uOPi-gaJpZM4VxHqm>
> .
>

#4 – bdring 于 2018-08-07

I have compared UGS job durations to other senders on a few short jobs and they appear to take the same time. The motion performance does not appear to be affected. When the DRO’s are sluggish, the motion is still running smoothly.

I used the Bluetooth to capture the data. UGS used a Bluetooth serial port and I had an Arduino IDE open on the USB serial port. All Bluetooth data is echo’e to the serial port before any processing.

Here is a portion of the data while the DRO’s are sluggish. At the beginning things are fine, then there is a big gap of ?’s, then ?’s return. If UGS runs fine on other Grbl, something could be different and confusing UGS.

?
?
?
?
ok
?
G1X12.306Y9.784F762.0
?
?
?
?
ok
G1X8.927Y6.897F762.0
?
ok
G1X8.224Y6.214F762.0
ok
?G1X8.399Y6.020F762.0
ok
G1X8.923Y5.883F762.0
ok
G1X14.205Y6.374F762.0
G1Z3.810F304.8
ok
G0X20.083Y42.239
ok
G1Z-1.000F304.8
ok
G1X21.258Y44.079F762.0
ok
G1X22.114Y45.096F762.0
ok
G1X23.123Y46.049F762.0
ok
ok
G1X25.771Y48.109F762.0
ok
G1X22.282Y51.598F762.0
ok
G1X18.792Y54.929F762.0
ok
G1X18.713Y56.555F762.0
ok
G1X18.203Y58.872F762.0
ok
G1X17.855Y59.814F762.0
ok
G1X16.969Y61.229F762.0
ok
G1X15.791Y62.412F762.0
ok
G1X14.389Y63.302F762.0
ok
G1X13.625Y63.620F762.0
ok
G1X12.829Y63.842F762.0
ok
G1X10.918Y64.032F762.0
ok
G1X9.021Y63.922F762.0
ok
G1X8.592Y63.807F762.0
?
ok
G1X8.351Y63.648F762.0
?
ok
G1X8.300Y63.451F762.0
?
ok
G1X8.443Y63.224F762.0
?

#5 – bdring 于 2018-08-07

Oops, maybe there is a missed one. Near the top of the gap is…?G1X8.399Y6.020F762.0. That ? has no response.

Most gcode senders send ? on a specified frequency regardless of a response, maybe UGS waits for a response and takes a while to try again.

Maybe there is a race condition and the flag to send the report is cleared early.

#6 – bdring 于 2018-08-08

@tgirard Try this.

I tried changing the data parser from setting a flag to printing immediately. Change the line around #83 in serial.cpp to this.

from…
case CMDSTATUSREPORT: systemsetexecstateflag(EXECSTATUSREPORT); break;
to…
case CMDSTATUSREPORT: reportrealtimestatus(); break;

I ran it on a few long jobs and it seems to work without any negative impacts. I tried a few other things, but they were affecting the step quality.

#7 – tgirard 于 2018-08-10

Hey Bart,
that change made all the difference in the DRO performance. I did a whole bunch of back and forth on all three axis’s and UGS performed the same as the .9 board (No-Load)
Closed as Fixed