qtvcp issues

More
12 Jan 2019 03:02 #124012 by cmorley
Replied by cmorley on topic qtvcp issues
I thank you for continued work and sharing it. It looks great.

Chris M

Please Log in or Create an account to join the conversation.

More
12 Jan 2019 03:07 #124013 by KCJ
Replied by KCJ on topic qtvcp issues
Indeed, that is a very nice looking screen. Keep it up!

Cheers,
Kurt

Please Log in or Create an account to join the conversation.

More
14 Jan 2019 02:22 #124133 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I have uploaded the present x1Mill gui development files to github. I have not had the time to make a simulation so these files are mainly to have a look at the present code. I will working on the code more because there is a lot more to be done. The gui .ui file will likely not need any more major changes.

Here is a direct link:

github.com/auto-mation-assist/x1Mill_bra...s/x1Mill_development

Please Log in or Create an account to join the conversation.

More
14 Jan 2019 06:53 #124139 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I left some unwanted things in the DRO area while trying to get the zoom in and out functions to work. I will upload a update tomorrow which will also have some other changes in the handler file.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
14 Jan 2019 07:06 #124140 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I’m working on getting the position jogging mode working that gets movement instructions from .ini file command lists but ran into a issue. The machine starts to move but then stops with and error.Which I find unusual since moved was started with a MDI command.

This is the code for the commands I entered with some print statement while I was debugging.

def pb_f12s6_1_jog_position_0_pressed(self):
print '>>>>> pb_f12s6_1_jog_position_0_pressed'
print '>>>>> SENDING CMD - self.cmnd.mode(linuxcnc.MODE_MDI)'
self.cmnd.mode(linuxcnc.MODE_MDI)
print '>>>>> SENDING CMD - self.cmnd.wait_complete()'
self.cmnd.wait_complete()
print '>>>>> SENDING CMD - self.cmnd.mdi(G01X0Y0Z0A0F2)'
self.cmnd.mdi('G01X0Y0Z0A0F2')
print '>>>>> SENDING CMD - self.cmnd.wait_complete()'
self.cmnd.wait_complete()
print '>>>>> SENDING CMD - self.cmnd.mode(linuxcnc.MODE_MANUAL)'
self.cmnd.mode(linuxcnc.MODE_MANUAL)
print '>>>>> SENDING CMD - self.cmnd.wait_complete()'
self.cmnd.wait_complete()

The result: It proceeds to move about .170 inches and then stops.

SW_5_index changed 0
manual mode
jog increment linear
Issuing EMC_JOG_INCR -- ( +125,+48, +18, +0,0.500000,-0.170000,)
SW_7_index changed 0
SW_6_index changed 1
SW_7_index changed 1
>>>>> LINE 1793: pb_f12s6_1_jog_position_0_pressed
>>>>> SENDING CMD - self.cmnd.mode(linuxcnc.MODE_MDI)
Issuing EMC_TASK_SET_MODE -- ( +504,+24, +19, +3,)
NML_INTERP_LIST(0x8c4980)::clear(): discarding 0 items
NML_INTERP_LIST(0x8c4980)::append(nml_msg_ptr{size=24,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
emcTaskPlanSynch() returned 0
NML_INTERP_LIST(0x8c4980)::get(): {size=24, type=EMC_TASK_PLAN_SYNCH}, list_size=0
emcTaskPlanLevel() returned 0
Issuing EMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
emcTaskPlanSynch() returned 0
>>>>> SENDING CMD - self.cmnd.wait_complete()
>>>>> SENDING CMD - self.cmnd.mdi(G01X0Y0Z0A0F2)
Issuing EMC_TASK_PLAN_EXECUTE -- ( +509,+280, +20,G01X0Y0Z0A0F2,)
emcTaskPlanLevel() returned 0
NML_INTERP_LIST(0x8c4980)::append(nml_msg_ptr{size=128,type=EMC_TRAJ_LINEAR_MOVE}) : list_size=1, line_number=0
emcTaskPlanExecute(G01X0Y0Z0A0F2) returned 0
emcTaskPlanLevel() returned 0
NML_INTERP_LIST(0x8c4980)::get(): {size=128, type=EMC_TRAJ_LINEAR_MOVE}, list_size=0
emcTaskPlanLevel() returned 0
Issuing EMC_TRAJ_LINEAR_MOVE -- ( +220,+128, +0,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000,0.000000, +2,0.031719,0.031719,0.095157, +0, -1,)
>>>>> SENDING CMD - self.cmnd.wait_complete()
>>>>> SENDING CMD - self.cmnd.mode(linuxcnc.MODE_MANUAL)
Issuing EMC_TASK_SET_MODE -- ( +504,+24, +21, +1,)
NML_INTERP_LIST(0x8c4980)::clear(): discarding 0 items
NML_INTERP_LIST(0x8c4980)::append(nml_msg_ptr{size=24,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
NML_INTERP_LIST(0x66d7e0)::clear(): discarding 0 items
NML_INTERP_LIST(0x8c4980)::clear(): discarding 1 items
NML_INTERP_LIST(0x8c4980)::append(nml_msg_ptr{size=24,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
NML_INTERP_LIST(0x8c4980)::get(): {size=24, type=EMC_TASK_PLAN_SYNCH}, list_size=0
emcTaskPlanLevel() returned 0
>>>>> SENDING CMD - self.cmnd.wait_complete()
Issuing EMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
emcTaskPlanSynch() returned 0
[QTvcp.QTVCP.WIDGETS.GCODE_EDITOR][ERROR] File path is not valid: (gcode_editor.py:371)
[QTvcp.QTVCP.WIDGETS.GCODE_EDITOR][ERROR] File path is not valid: (gcode_editor.py:371)

Please Log in or Create an account to join the conversation.

More
14 Jan 2019 08:12 #124142 by cmorley
Replied by cmorley on topic qtvcp issues
My guess would be the mode changes.
Hard to tell without the code used to call the MDI calls.

I would also suggest using the ACTION library rather then calling commands directly.

Chris M

Please Log in or Create an account to join the conversation.

More
14 Jan 2019 16:57 #124168 by newbynobi
Replied by newbynobi on topic qtvcp issues
Even giving the statement "wait complete" will not force linuxcnc to wait for finishing the command prior to the mode change.

I use a workaround in gmoccapy, i.e. for reload tool on startup, I set self.change_tool to True, then I change the mode and hal status will emit the changed mode signal. I do not change modes in GUI, as change_tool is set, but if the GUI gets the hal status signal interpreter idle, I check if change tool is set and change back to manual mode.

I did not find any other solution to avoid a visible mode change.

Norbert

Please Log in or Create an account to join the conversation.

More
15 Jan 2019 06:21 - 15 Jan 2019 06:27 #124222 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
Norbert

I have never played much with the wait statements and found out that like you said they do not wait before the next command to change modes back to manual is sent. To fix this I wrote some code that gets called after movement is done and status 'inpos' returns to True if the movement was created by my position command and 'task_mode' 3 is valid. Thus three checks are made before the command is sent to switch back to manual mode. These checks are by passed when not needed to avoid eating up processing time.

It is working fine now with minimum delay.

I suspect that the QTvcp gcode editor may still be in play even tough it is likely not needed for sending MDI commands to linuxcnc.

mdi_execute_hook: MDI command 'G01 X0 Y0 Z0 A0 F4' done (remaining: 0)
Issuing EMC_TASK_SET_MODE -- ( +504,+24, +20, +1,)
NML_INTERP_LIST(0x8c4980)::clear(): discarding 0 items
NML_INTERP_LIST(0x8c4980)::append(nml_msg_ptr{size=24,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
NML_INTERP_LIST(0x66d7e0)::clear(): discarding 0 items
NML_INTERP_LIST(0x8c4980)::clear(): discarding 1 items
NML_INTERP_LIST(0x8c4980)::append(nml_msg_ptr{size=24,type=EMC_TASK_PLAN_SYNCH}) : list_size=1, line_number=0
NML_INTERP_LIST(0x8c4980)::get(): {size=24, type=EMC_TASK_PLAN_SYNCH}, list_size=0
emcTaskPlanLevel() returned 0
task: main loop took 0.011272 seconds
Issuing EMC_TASK_PLAN_SYNCH -- ( +516,+24, +0,)
emcTaskPlanSynch() returned 0
task: main loop took 0.041458 seconds
mdi position cmd completed

I also worked on the homing page and now have buttons for homing all axis at once or individual axis. It is also working with no issues noted. The next most important thing is a tool page and since I'm used to your layout, which has worked well for me I will see if I can make something similar for Qtvcp.
Last edit: 15 Jan 2019 06:27 by auto-mation-assist.

Please Log in or Create an account to join the conversation.

More
15 Jan 2019 06:25 #124223 by auto-mation-assist
Replied by auto-mation-assist on topic qtvcp issues
I forgot to add:

Can someone explain to me what the numbers in these mean.

Issuing EMC_TASK_SET_MODE -- ( +504,+24, +20, +1,)

Please Log in or Create an account to join the conversation.

More
15 Jan 2019 06:29 #124224 by newbynobi
Replied by newbynobi on topic qtvcp issues
Does your way also work correct, if no movement is involved?
What if we just send a G4 P1 or M61 Q2 or just a (MSG, Hallo world)

I had Problems with that.

Norbert

Please Log in or Create an account to join the conversation.

Moderators: cmorley
Time to create page: 0.184 seconds
Powered by Kunena Forum