Re: [Emc-developers] Python <-> HAL interfacing
> As a member of the board, I am 100% in favor of PyVCP becoming part of > EMC2. > (Yeah, I know this is late, you've already committed it. I was away > for several days.) > As the original author of VCP (the C version) I'm also very happy to > see PyVCP. It looks like you have already taken PyVCP farther in a > week or less than VCP came in the year(ish) since I first started it. > I think having both PyVCP and VCP might be wastefull or confusing, but > from what I've seen so far, I'd scrap VCP and keep the python version. Thanks for your comments John. Thanks to Jeff Epler it's now fairly easy to try out pyVCP in AXIS (you need the latest HEAD, naturally). You specify: PYVCP = lathe.xml in the [DISPLAY] section of the ini file. The created axisui.xxx HAL pins can be hooked up by running a HAL script after AXIS has loaded. That's specified with POSTGUI_HALFILE = lathe_postgui.hal in the [HAL] section. the filenames above are from the sim/lathe config, which shows how the spindle speed can be displayed with a bar widget. emc2/configs/sim/pyvcp_demo.xml contains the example panel that is posted on the wiki. So it looks like pyVCP is going to be useful at least for AXIS users. Other GUI's could run the pyVCP parser similarly, but create a separate window for the pyVCP panel. I'm not sure how this is done, and since I use AXIS exclusively I'm not that eager to fix this... Those familiar with commercial cnc-controls might suggest some useful widgets that we are still missing ? Anders - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Python <-> HAL interfacing
Most commercial CNC controls are far behind EMC. >From what I have seen. > Those familiar with commercial cnc-controls might suggest some useful > widgets that we are still missing ? > > Anders > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Python <-> HAL interfacing
Mario. wrote: >Most commercial CNC controls are far behind EMC. >>From what I have seen. > > > >>Those familiar with commercial cnc-controls might suggest some useful >>widgets that we are still missing ? >> >> >> The big thing on most "big name" controls is the ability to hop around in the program at will. Even my 1978 Allen-Bradley 7320 control on a 16-bit minicomputer allowed you to punch buttons and skip forward or back through the program. If a block didn't cut to the right dimension, you could punch manual, creep an axis a bit, then alter the coordinate alignment, back up a couple blocks and hit cycle start, and it would redo that block. It was easy to executa a couple MDI commands in the middle of a program, and then resume the program from where you interrupted it. This is the big one that I still miss. Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Python <-> HAL interfacing
I think the tools are there ("run from line"), at least when O-words
aren't being used--strictly the old-style g-codes. And unlike in the
past, verify and run-from-line are both quite fast to process even
10,000 lines.
The trick is to make it more transparent to the user -- replace pause
with this new button, which actually stops the program and lets them
drop back to manual and mdi, then when pressed again automatically use
"run from line" and restart from where they left off.
The other trick is knowing when this can't be done -- probably anytime
you're in an 'O- while' or 'O- sub'. but this will feel to the user
like an arbitrary restriction.
Actually, there are probably more problems than O- words: consider a
canned cycle with a L- repeat, or incremental motion mode, or other
things I haven't thought of yet.
So forget it -- this is a hard topic, with no easy solutions.
Jeff
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Python <-> HAL interfacing
Jeff Epler wrote:
>I think the tools are there ("run from line"), at least when O-words
>aren't being used--strictly the old-style g-codes. And unlike in the
>past, verify and run-from-line are both quite fast to process even
>10,000 lines.
>
>
>
I haven't worked with this much, but the speedup is certainly a major
improvement
for users with large programs.
>The trick is to make it more transparent to the user -- replace pause
>with this new button, which actually stops the program and lets them
>drop back to manual and mdi, then when pressed again automatically use
>"run from line" and restart from where they left off.
>
>
>
Yes, transparency really helps.
>The other trick is knowing when this can't be done -- probably anytime
>you're in an 'O- while' or 'O- sub'. but this will feel to the user
>like an arbitrary restriction.
>
>
>
Yes, there are a MILLION possible ways to get into trouble here. Such
as pausing where
the mode is set to G03, and then backing up to a line that was written
with the mode
in G01, with X1.23 Y2.34, and of course there won't be an R or I,J word,
so it croaks.
>Actually, there are probably more problems than O- words: consider a
>canned cycle with a L- repeat, or incremental motion mode, or other
>things I haven't thought of yet.
>
>So forget it -- this is a hard topic, with no easy solutions.
>
>
>
No, I WON'T forget it. It IS up to the operator to know what he CAN,
and CAN'T do!
Good diagnostic messages help, and EMC does give pretty good ones, a LOT
better
than the AB 7320. Many errors would just do crazy moves, or the lighted
cycle start
button would just go out, with no message. Many of the looping
procedures leave
things in particular variables, so they should be restartable from the
middle. If you
want to re-run the whole loop, then you have to back up to the block
that initialized
the variables for the loop. You do have to know what you are doing, and
know the
logic of the G-code being run. But, nobody generates a million-block
program
manually, with a bunch of loops, etc. in it. Most CAD packages we can
afford won't
do that, or subroutines, either.
Perhaps more modern commercial CNC controls handle all these
intricacies, but I
wouldn't be surprised if they don't.
Jon
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
