blurfl
Thank you so much for your attention. I recall that you had indicated that the GC only reports the value that the Arduino is reporting in status. Is that the case?
I have a programming background, but do not begin to understand how the software works and what the distribution of functions across the python GC and the c/c++ Arduino are.
I have taken a look however at the reporting procedure calls in the Python and have seen the following:
from line 341` in main.py ------------
def runPeriodically(self, *args):
‘’’
this block should be handled within the appropriate widget
‘’’
while not self.data.message_queue.empty(): #if there is new data to be read
message = self.data.message_queue.get()
if message[0] == "<":
self.setPosOnScreen(message)
This section seems to be detecting if the message_queue is not empty(from the arduino)and if so places the current position on the screen. That seems to be async to the operation depending on when the arduino sends a status message.
It would seem though that when I run the device, and when the gcode is running with G0 Z moves in the file, that the machine waits for the G0 Z move to complete - then updates the position(has been updating continually during the move to completion) - and at completion moves on to the next gcode statement in the buffer.
from line 370 in frontPage.pu -------------
def sendLine(self):
try:
self.data.gcode_queue.put(self.data.gcode[self.data.gcodeIndex])
self.data.gcodeIndex = self.data.gcodeIndex + 1
except:
print “gcode run complete”
self.gcodecanvas.uploadFlag = 0
self.data.gcodeIndex = 0
This code is responsible for the transfer of the next gcode line into the queue to be sent to the machine. As I said, the machine seems to wait for each of the G0 Z moves. There may be an opportunity to check whether the Z value in the position message
self.setPosOnScreen(message)
equals the gcode command sent in the
self.data.gcode_queue.put(self.data.gcode[self.data.gcodeIndex])
command.
I believe these values are already parsed out of the messages, so the SW may be able to test the properties with respect to the outgoing and incoming z values to see if the sleds z value fell behind.
These actions may not be fully synchronized, but seem to have some wait and continue logic to it.
Further, this action would only be flagged if the Gcode command being sent to the arduino contained a z value change. This would allow for checking only in z moves.
This is just a thought on approach. I will raise this issue now in the Firmware section in the forum because it would appear to be a fault in the arduino code. I have seen comments in the arduino source code already that ask why the Z motion is handled differently in the code than the x and y is. I know it is related to the fact that x and y motions depend on the triangular calculations for correct motor motions, and the z motion is a straight step to operation. The position read and sensing for keeping up however should be the same.
Thanks again for all of your help and attention.