Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's, whats next?

[Gene Heskett]

On Thursday 16 February 2017 12:06:41 Nicklas Karlsson wrote:

> First you have to run the rip enviroment script:
>   . rip-environment
> Then you have to run glade at the same prompt and I think this will
> run the correct version glade-3
>
>
> This worked for me and it is very simple to use. I found a few things
> I think could be improved in the widgets but are very happy anyway and
> will probably take a look at this then I got enough time.
>
That would be great, Nicklas. ATM its no hurry as it will take me a while 
to make the mounting brackets for this stuff when it does arrive.  
Thanks.
>
> On Wed, 15 Feb 2017 21:38:15 -0500
>
> Gene Heskett  wrote:
> > Greetings guys;
> >
> > I just spent an hour, both on this machine,  and on the pi, trying
> > to make the one example gvcp-panel.test.ui we have, run. I can get a
> > tiny led out of it on this wheezy machine, but Glade 3+ on the pi
> > knows nothing of the widget creation commands in that file.  ,
> > HAL_LED, 95% of the file is an error report.
> >
> > So it looks like gtk2+ is officially shitcanned.
> >
> > Except all the /usr/lib/python2.7/gladevcp stuff is there on the pi,
> > I think:
> > ls =
> > calculator.glade  gladebuilder.pyc hal_filechooser.py
> > hal_lightbutton.py   hal_pythonplugin.py   __init__.py
> > offsetpage.glade   persistence.pyc
> > calculatorwidget.py   gladevcp-test.glade  hal_filechooser.pyc
> > hal_lightbutton.pyc  hal_pythonplugin.pyc  __init__.pyc
> > offsetpage_widget.py   speedcontrol.py
> > calculatorwidget.pyc  hal_actions.py   hal_graph.py
> > hal_mdihistory.pyhal_sourceview.py jogwheel.py
> > offsetpage_widget.pyc  speedcontrol.pyc
> > combi_dro.py  hal_actions.pyc  hal_graph.pyc
> > hal_mdihistory.pyc   hal_sourceview.pycjogwheel.pyc 
> > offsetwidget.py tooledit_gtk.glade
> > combi_dro.pyc hal_bar.py   hal_gremlin_plus.py
> > hal_meter.py hal_widgets.pyled.py
> > offsetwidget.pyc   tooledit_widget.py
> > drowidget.py  hal_bar.pyc  hal_gremlin_plus.pyc
> > hal_meter.pychal_widgets.pyc   led.pyc
> > overridewidget.py  tooledit_widget.pyc
> > drowidget.pyc hal_dial.py  hal_gremlin.py
> > hal_pyngcgui.py  iconview.py   makepins.py
> > overridewidget.pyc xembed.py
> > gladebuilder.py   hal_dial.pyc hal_gremlin.pyc
> > hal_pyngcgui.pyc iconview.pyc  makepins.pyc 
> > persistence.py xembed.pyc
> >
> > I did find a 3 yo msg with google that recommended setting up env
> > vars with export for where it was, found the python-2.7 versions and
> > exported that path, but if it helped I didn't/couldn't tell.
> > glade-3.18.xx apparently can't use it.
> >
> > What do we do next? pyvcp I am told cannot do what I want.
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > Genes Web page 
> >
> > 
> >-- Check out the vibrant tech community on one of the world's
> > most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> Check out the vibrant tech community on one of the world's
> most engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's, whats next?

[Gene Heskett]

On Thursday 16 February 2017 11:42:46 Todd Zuercher wrote:

> The tabs don't have to encompass the whole pyvcp window, only the
> items in the box that needs to change.  I can't guess how much load it
> may add to your puny little pi.  Can't imagine it would be a whole
> lot.

I was thinking of its only a gig of ram.  Every other machine on the 
premesis has 2G's minimum.

> Unfortunately I don't think pyvcp does dynamic anything (hence why the
> tabs hack to start with) including using anything other than a mouse
> click for selecting the tabs.
>
Only partially true, Todd. The mouse click HAS to enter the pyvcp code 
somehow, and if a mouse click can get in, so can the output of a couple 
comparators being driven by these detectors I'll put in if they worek 
well. I don't want them full time active, but if I stop the spindle and 
move the belt to a different position, the comparator should be able to 
output from an edge detector whose output has been debounced for say 5 
seconds, then store the detector state in 4 or 5 mu2's. Then send the 
tab control whichever detector is matching the current state.  That 
could handle the tach display only.  And I've already got a triplet of 
leds to tell me I need to change gears written into in the xml file.  
But none of the hal code for that has been written yet. Plus I already 
have 3 more leds above those three, first one turns green when 
motion.motion-enabled is true, else red, and two more that are red 
normally, but turn green to show fwd or rev.  Tied to the raw velocity 
from the encoder. The chuck only has to move 2 degrees to turn one of 
them green for about 1/2 a second.  Thats live full time as its tapped 
off the encoder in parallel with the rigid tapping stuff.  So I think 
its possible

I just haven't commanded froggy to wave the Magic Twanger yet... ;-)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G41-42 and G64 Bug?q

[Todd Zuercher]

Maybe, it is or isn't a problem.
The g-code is only:

G43
G0 X1.5 Y.375 Z1
G41
G1X1Y.5Z.5
G1X0.5
G2 X4.5 I2 J0
G1 X0.75
G0Z1
G40

It runs perfectly fine without the G41 reguardless of the G64 setting. I guess 
the planner must see that arc in the transition from one line to the next in 
G41 and the Q is acting it, even though it isn't actually written in the 
g-code. 
Something else to remember when using tool comp.


- Original Message -
From: "sam sokolik" 
To: "Enhanced Machine Controller (EMC)" 
Sent: Thursday, February 16, 2017 3:20:02 PM
Subject: Re: [Emc-users] G41-42 and G64 Bug?

On this post - I showed what happens to a shape as you increase Q

http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/206712-software.html#post1453562

sam

On 2/16/2017 2:11 PM, Kurt Jacobson wrote:
> OK, I see that you mean now. As they say, a picture is worth a thousand
> words. (Though that does not seem to hold true when writing an essay for
> English class!?)
>
> I still think naive cam detector is doing exactly what it is suposed to. If
> the maximum deviation of an arc from a strait line is within Q they are
> collapsed into a single linear move, which is exactly what I see in your
> screen dump.
>
> Kurt
>
> On Thu, Feb 16, 2017 at 2:53 PM, Todd Zuercher 
> wrote:
>
>> I didn't expect the Naive cam detection to do this.
>> https://s2.postimg.org/ezy3wjfjt/bug.png
>> Maybe I am reading the docs wrong.
>>
>> - Original Message -
>> From: "Kurt Jacobson" 
>> To: "Enhanced Machine Controller (EMC)" 
>> Sent: Thursday, February 16, 2017 2:10:26 PM
>> Subject: Re: [Emc-users] G41-42 and G64 Bug?
>>
>> I don't really know any thing about this, but I'd say that is the expected
>> behavior based on the description of G64 Path Blending:
>>
>> "On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc
>> from a straight line is less than the G64 P- tolerance the arc is broken
>> into two lines (from start of arc to midpoint, and from midpoint to end).
>> those lines are then subject to the naive cam algorithm for lines.[1]"
>>
>> It sounds like your Q value is larger than the radius of your compensation
>> lead out, so the arc is broken up into two line segments. Since these line
>> segments are within Q of a linear move they are collapsed into one linear
>> move, and since this linear move is within Q of the original linear move
>> the whole path is collapsed in to a single linear move which is treated
>> essentially becomes a long compensation lead out move.
>>
>> Just thinking out loud here, again, I am a complete noob so take this with
>> half a grain of salt.
>>
>> [1] http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g61-g61.1
>>
>> Kurt
>>
>> On Thu, Feb 16, 2017 at 1:32 PM, Todd Zuercher 
>> wrote:
>>
>>> I was playing arround with G41 and G42 in a simulation and I think I
>> might
>>> have found a bug with the Naive CAM Detection.
>>> The shape I was simulating was a semi circle with the start/end point on
>>> the flat side and a single G2 arc move connecting the end points.
>>> The simulation behaves strangely. With a tool radius of .125" and .25"
>> and
>>> staight G64 the tool path precisely followed the path (white and red
>> lines
>>> over lapped). With G64P0.001, the same. The expected behavior is cutting
>> a
>>> straight line parallel to the programed line offset the tool radius, cut
>> an
>>> arc around that end point to connect to the offset path of the commanded
>>> arc cut. all good right.
>>> With G64P0.001Q0.2 there is odd behavior. It moves in a straight line
>> from
>>> the beginning of the compensated straight line cut to the begining of the
>>> compensated arc cut completely ignoring the compensated end point of the
>>> straight cut. I know having such a large Q setting is a little odd. I
>> also
>>> see simular behavior with G64P0.2 (no Q specified, same as Q0.2) only
>> with
>>> more rounded corners.
>>> I seem to see the odd behavior when ever Q is about 2/3 or more than the
>>> tool diameter.
>>>
>>> --
>>>
>>> 
>>>
>>> Todd Zuercher
>>> mailto:zuerc...@embarqmail.com
>>>
>>> 
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>> -

Re: [Emc-users] G41-42 and G64 Bug?

[sam sokolik]

On this post - I showed what happens to a shape as you increase Q

http://www.cnczone.com/forums/linuxcnc-formerly-emc2-/206712-software.html#post1453562

sam

On 2/16/2017 2:11 PM, Kurt Jacobson wrote:
> OK, I see that you mean now. As they say, a picture is worth a thousand
> words. (Though that does not seem to hold true when writing an essay for
> English class!?)
>
> I still think naive cam detector is doing exactly what it is suposed to. If
> the maximum deviation of an arc from a strait line is within Q they are
> collapsed into a single linear move, which is exactly what I see in your
> screen dump.
>
> Kurt
>
> On Thu, Feb 16, 2017 at 2:53 PM, Todd Zuercher 
> wrote:
>
>> I didn't expect the Naive cam detection to do this.
>> https://s2.postimg.org/ezy3wjfjt/bug.png
>> Maybe I am reading the docs wrong.
>>
>> - Original Message -
>> From: "Kurt Jacobson" 
>> To: "Enhanced Machine Controller (EMC)" 
>> Sent: Thursday, February 16, 2017 2:10:26 PM
>> Subject: Re: [Emc-users] G41-42 and G64 Bug?
>>
>> I don't really know any thing about this, but I'd say that is the expected
>> behavior based on the description of G64 Path Blending:
>>
>> "On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc
>> from a straight line is less than the G64 P- tolerance the arc is broken
>> into two lines (from start of arc to midpoint, and from midpoint to end).
>> those lines are then subject to the naive cam algorithm for lines.[1]"
>>
>> It sounds like your Q value is larger than the radius of your compensation
>> lead out, so the arc is broken up into two line segments. Since these line
>> segments are within Q of a linear move they are collapsed into one linear
>> move, and since this linear move is within Q of the original linear move
>> the whole path is collapsed in to a single linear move which is treated
>> essentially becomes a long compensation lead out move.
>>
>> Just thinking out loud here, again, I am a complete noob so take this with
>> half a grain of salt.
>>
>> [1] http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g61-g61.1
>>
>> Kurt
>>
>> On Thu, Feb 16, 2017 at 1:32 PM, Todd Zuercher 
>> wrote:
>>
>>> I was playing arround with G41 and G42 in a simulation and I think I
>> might
>>> have found a bug with the Naive CAM Detection.
>>> The shape I was simulating was a semi circle with the start/end point on
>>> the flat side and a single G2 arc move connecting the end points.
>>> The simulation behaves strangely. With a tool radius of .125" and .25"
>> and
>>> staight G64 the tool path precisely followed the path (white and red
>> lines
>>> over lapped). With G64P0.001, the same. The expected behavior is cutting
>> a
>>> straight line parallel to the programed line offset the tool radius, cut
>> an
>>> arc around that end point to connect to the offset path of the commanded
>>> arc cut. all good right.
>>> With G64P0.001Q0.2 there is odd behavior. It moves in a straight line
>> from
>>> the beginning of the compensated straight line cut to the begining of the
>>> compensated arc cut completely ignoring the compensated end point of the
>>> straight cut. I know having such a large Q setting is a little odd. I
>> also
>>> see simular behavior with G64P0.2 (no Q specified, same as Q0.2) only
>> with
>>> more rounded corners.
>>> I seem to see the odd behavior when ever Q is about 2/3 or more than the
>>> tool diameter.
>>>
>>> --
>>>
>>> 
>>>
>>> Todd Zuercher
>>> mailto:zuerc...@embarqmail.com
>>>
>>> 
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> 

Re: [Emc-users] G41-42 and G64 Bug?

[Kurt Jacobson]

OK, I see that you mean now. As they say, a picture is worth a thousand
words. (Though that does not seem to hold true when writing an essay for
English class!?)

I still think naive cam detector is doing exactly what it is suposed to. If
the maximum deviation of an arc from a strait line is within Q they are
collapsed into a single linear move, which is exactly what I see in your
screen dump.

Kurt

On Thu, Feb 16, 2017 at 2:53 PM, Todd Zuercher 
wrote:

> I didn't expect the Naive cam detection to do this.
> https://s2.postimg.org/ezy3wjfjt/bug.png
> Maybe I am reading the docs wrong.
>
> - Original Message -
> From: "Kurt Jacobson" 
> To: "Enhanced Machine Controller (EMC)" 
> Sent: Thursday, February 16, 2017 2:10:26 PM
> Subject: Re: [Emc-users] G41-42 and G64 Bug?
>
> I don't really know any thing about this, but I'd say that is the expected
> behavior based on the description of G64 Path Blending:
>
> "On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc
> from a straight line is less than the G64 P- tolerance the arc is broken
> into two lines (from start of arc to midpoint, and from midpoint to end).
> those lines are then subject to the naive cam algorithm for lines.[1]"
>
> It sounds like your Q value is larger than the radius of your compensation
> lead out, so the arc is broken up into two line segments. Since these line
> segments are within Q of a linear move they are collapsed into one linear
> move, and since this linear move is within Q of the original linear move
> the whole path is collapsed in to a single linear move which is treated
> essentially becomes a long compensation lead out move.
>
> Just thinking out loud here, again, I am a complete noob so take this with
> half a grain of salt.
>
> [1] http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g61-g61.1
>
> Kurt
>
> On Thu, Feb 16, 2017 at 1:32 PM, Todd Zuercher 
> wrote:
>
> > I was playing arround with G41 and G42 in a simulation and I think I
> might
> > have found a bug with the Naive CAM Detection.
> > The shape I was simulating was a semi circle with the start/end point on
> > the flat side and a single G2 arc move connecting the end points.
> > The simulation behaves strangely. With a tool radius of .125" and .25"
> and
> > staight G64 the tool path precisely followed the path (white and red
> lines
> > over lapped). With G64P0.001, the same. The expected behavior is cutting
> a
> > straight line parallel to the programed line offset the tool radius, cut
> an
> > arc around that end point to connect to the offset path of the commanded
> > arc cut. all good right.
> > With G64P0.001Q0.2 there is odd behavior. It moves in a straight line
> from
> > the beginning of the compensated straight line cut to the begining of the
> > compensated arc cut completely ignoring the compensated end point of the
> > straight cut. I know having such a large Q setting is a little odd. I
> also
> > see simular behavior with G64P0.2 (no Q specified, same as Q0.2) only
> with
> > more rounded corners.
> > I seem to see the odd behavior when ever Q is about 2/3 or more than the
> > tool diameter.
> >
> > --
> >
> > 
> >
> > Todd Zuercher
> > mailto:zuerc...@embarqmail.com
> >
> > 
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G41-42 and G64 Bug?

[Todd Zuercher]

I didn't expect the Naive cam detection to do this.
https://s2.postimg.org/ezy3wjfjt/bug.png
Maybe I am reading the docs wrong.

- Original Message -
From: "Kurt Jacobson" 
To: "Enhanced Machine Controller (EMC)" 
Sent: Thursday, February 16, 2017 2:10:26 PM
Subject: Re: [Emc-users] G41-42 and G64 Bug?

I don't really know any thing about this, but I'd say that is the expected
behavior based on the description of G64 Path Blending:

"On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc
from a straight line is less than the G64 P- tolerance the arc is broken
into two lines (from start of arc to midpoint, and from midpoint to end).
those lines are then subject to the naive cam algorithm for lines.[1]"

It sounds like your Q value is larger than the radius of your compensation
lead out, so the arc is broken up into two line segments. Since these line
segments are within Q of a linear move they are collapsed into one linear
move, and since this linear move is within Q of the original linear move
the whole path is collapsed in to a single linear move which is treated
essentially becomes a long compensation lead out move.

Just thinking out loud here, again, I am a complete noob so take this with
half a grain of salt.

[1] http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g61-g61.1

Kurt

On Thu, Feb 16, 2017 at 1:32 PM, Todd Zuercher 
wrote:

> I was playing arround with G41 and G42 in a simulation and I think I might
> have found a bug with the Naive CAM Detection.
> The shape I was simulating was a semi circle with the start/end point on
> the flat side and a single G2 arc move connecting the end points.
> The simulation behaves strangely. With a tool radius of .125" and .25" and
> staight G64 the tool path precisely followed the path (white and red lines
> over lapped). With G64P0.001, the same. The expected behavior is cutting a
> straight line parallel to the programed line offset the tool radius, cut an
> arc around that end point to connect to the offset path of the commanded
> arc cut. all good right.
> With G64P0.001Q0.2 there is odd behavior. It moves in a straight line from
> the beginning of the compensated straight line cut to the begining of the
> compensated arc cut completely ignoring the compensated end point of the
> straight cut. I know having such a large Q setting is a little odd. I also
> see simular behavior with G64P0.2 (no Q specified, same as Q0.2) only with
> more rounded corners.
> I seem to see the odd behavior when ever Q is about 2/3 or more than the
> tool diameter.
>
> --
>
> 
>
> Todd Zuercher
> mailto:zuerc...@embarqmail.com
>
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] G41-42 and G64 Bug?

[Kurt Jacobson]

I don't really know any thing about this, but I'd say that is the expected
behavior based on the description of G64 Path Blending:

"On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc
from a straight line is less than the G64 P- tolerance the arc is broken
into two lines (from start of arc to midpoint, and from midpoint to end).
those lines are then subject to the naive cam algorithm for lines.[1]"

It sounds like your Q value is larger than the radius of your compensation
lead out, so the arc is broken up into two line segments. Since these line
segments are within Q of a linear move they are collapsed into one linear
move, and since this linear move is within Q of the original linear move
the whole path is collapsed in to a single linear move which is treated
essentially becomes a long compensation lead out move.

Just thinking out loud here, again, I am a complete noob so take this with
half a grain of salt.

[1] http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g61-g61.1

Kurt

On Thu, Feb 16, 2017 at 1:32 PM, Todd Zuercher 
wrote:

> I was playing arround with G41 and G42 in a simulation and I think I might
> have found a bug with the Naive CAM Detection.
> The shape I was simulating was a semi circle with the start/end point on
> the flat side and a single G2 arc move connecting the end points.
> The simulation behaves strangely. With a tool radius of .125" and .25" and
> staight G64 the tool path precisely followed the path (white and red lines
> over lapped). With G64P0.001, the same. The expected behavior is cutting a
> straight line parallel to the programed line offset the tool radius, cut an
> arc around that end point to connect to the offset path of the commanded
> arc cut. all good right.
> With G64P0.001Q0.2 there is odd behavior. It moves in a straight line from
> the beginning of the compensated straight line cut to the begining of the
> compensated arc cut completely ignoring the compensated end point of the
> straight cut. I know having such a large Q setting is a little odd. I also
> see simular behavior with G64P0.2 (no Q specified, same as Q0.2) only with
> more rounded corners.
> I seem to see the odd behavior when ever Q is about 2/3 or more than the
> tool diameter.
>
> --
>
> 
>
> Todd Zuercher
> mailto:zuerc...@embarqmail.com
>
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] G41-42 and G64 Bug?

[Todd Zuercher]

I was playing arround with G41 and G42 in a simulation and I think I might have 
found a bug with the Naive CAM Detection. 
The shape I was simulating was a semi circle with the start/end point on the 
flat side and a single G2 arc move connecting the end points. 
The simulation behaves strangely. With a tool radius of .125" and .25" and 
staight G64 the tool path precisely followed the path (white and red lines over 
lapped). With G64P0.001, the same. The expected behavior is cutting a straight 
line parallel to the programed line offset the tool radius, cut an arc around 
that end point to connect to the offset path of the commanded arc cut. all good 
right. 
With G64P0.001Q0.2 there is odd behavior. It moves in a straight line from the 
beginning of the compensated straight line cut to the begining of the 
compensated arc cut completely ignoring the compensated end point of the 
straight cut. I know having such a large Q setting is a little odd. I also see 
simular behavior with G64P0.2 (no Q specified, same as Q0.2) only with more 
rounded corners. 
I seem to see the odd behavior when ever Q is about 2/3 or more than the tool 
diameter. 

-- 

 

Todd Zuercher 
mailto:zuerc...@embarqmail.com 

 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] vfd compatibility

[Valerio Bellizzomi]

On Thu, 2017-02-16 at 08:56 -0800, Kirk Wallace wrote:
> On 02/16/2017 03:37 AM, Valerio Bellizzomi wrote:
> ... snip
> > the VFD is a Toshiba VFS15-4037PL-W, it has a Forward input, a Reverse
> > input, and a current speed input (and alternatively a 0-10V input).
> > There isn't an enable input. I do not need the reverse so it should be
> > two parallel pins, one for forward and one for speed.
> ... snip
> 
> I found a manual here:
> https://inverterdrive.com/file/Toshiba-VFS15-User-Manual
> 
> I usually first check the overview graphic which seems to be on page 
> B-4. I see the F terminal which could just be shorted to common to 
> activate it. The speed potentiometer is shown too. PWM could simulate 
> that. I also see theRS485 connector. I did a search in the document for 
> "485" and found page C-4, which shows some control options; terminal 
> (relay), keypad, RS485 (Modbus?), CAN (cool), communication(what the 
> heck?). Just below are some speed setting options. This should be a nice 
> VFD.
> 
> A little farther down from B-4 are the I/O circuit options. Looking at 
> the F entry, it basically says shorting the F terminal to CC will start 
> forward rotation. You can use a parallel port pin to control a small 
> solid state relay or opto-isolator. It just needs to tolerate 24 Volts 
> on the output.

Yes that is what I said, there is no Enable, just Forward and Reverse,
to be connected to CC 


> It looks like the VIA (voltage, input, analog?) is a speed input. The 
> same parallel port pin to solid state relay or opto-isolator as F above 
> may be used, except it only needs 10 Volt tolerence. Terminal PP is the 
> 10 Volt source (CC common isn't needed, most likely). The signal from 
> the parallel port pin should use PWM or PDM.

>From the manual's figure (page C-13), the VIA is for an external
potentiometer, or for a voltage input, the VIB is for a voltage input,
and VIC is for current input. The input mode is programmable with the
cnod/fnod parameters on the vfd

> If you have a BOB (Break Out Board), post a make/model and/or picture or 
> other information. It may be useful for the above connections.
> 
> It looks like page D-3 is a good place to start VFD programing.
> 
> The above may be wrong or missing some information, so study the manual 
> and decide for yourself what to do. I would get a mains input noise 
> filter right of the bat, so you don't have to chase down weird issues 
> while trying to learn how to use your VFD. Hmm... It looks like your VFD 
> already has a built-in noise filter.

It has a selectable noise filter (on/off)





--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's, whats next?

[Nicklas Karlsson]

First you have to run the rip enviroment script:
  . rip-environment
Then you have to run glade at the same prompt and I think this will run the 
correct version
  glade-3


This worked for me and it is very simple to use. I found a few things I think 
could be improved in the widgets but are very happy anyway and will probably 
take a look at this then I got enough time.


On Wed, 15 Feb 2017 21:38:15 -0500
Gene Heskett  wrote:

> Greetings guys;
> 
> I just spent an hour, both on this machine,  and on the pi, trying to 
> make the one example gvcp-panel.test.ui we have, run. I can get a tiny 
> led out of it on this wheezy machine, but Glade 3+ on the pi knows 
> nothing of the widget creation commands in that file.  , HAL_LED, 
> 95% of the file is an error report.
> 
> So it looks like gtk2+ is officially shitcanned.
> 
> Except all the /usr/lib/python2.7/gladevcp stuff is there on the pi, I 
> think:
> ls =
> calculator.glade  gladebuilder.pyc hal_filechooser.py
> hal_lightbutton.py   hal_pythonplugin.py   __init__.py   
> offsetpage.glade   persistence.pyc
> calculatorwidget.py   gladevcp-test.glade  hal_filechooser.pyc   
> hal_lightbutton.pyc  hal_pythonplugin.pyc  __init__.pyc  
> offsetpage_widget.py   speedcontrol.py
> calculatorwidget.pyc  hal_actions.py   hal_graph.py  
> hal_mdihistory.pyhal_sourceview.py jogwheel.py   
> offsetpage_widget.pyc  speedcontrol.pyc
> combi_dro.py  hal_actions.pyc  hal_graph.pyc 
> hal_mdihistory.pyc   hal_sourceview.pycjogwheel.pyc  offsetwidget.py  
>   
> tooledit_gtk.glade
> combi_dro.pyc hal_bar.py   hal_gremlin_plus.py   
> hal_meter.py hal_widgets.pyled.py
> offsetwidget.pyc   tooledit_widget.py
> drowidget.py  hal_bar.pyc  hal_gremlin_plus.pyc  
> hal_meter.pychal_widgets.pyc   led.pyc   
> overridewidget.py  tooledit_widget.pyc
> drowidget.pyc hal_dial.py  hal_gremlin.py
> hal_pyngcgui.py  iconview.py   makepins.py   
> overridewidget.pyc xembed.py
> gladebuilder.py   hal_dial.pyc hal_gremlin.pyc   
> hal_pyngcgui.pyc iconview.pyc  makepins.pyc  persistence.py   
>   
> xembed.pyc
> 
> I did find a 3 yo msg with google that recommended setting up env vars 
> with export for where it was, found the python-2.7 versions and exported 
> that path, but if it helped I didn't/couldn't tell. glade-3.18.xx 
> apparently can't use it.
> 
> What do we do next? pyvcp I am told cannot do what I want.
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] vfd compatibility

[Kirk Wallace]

On 02/16/2017 03:37 AM, Valerio Bellizzomi wrote:
... snip
> the VFD is a Toshiba VFS15-4037PL-W, it has a Forward input, a Reverse
> input, and a current speed input (and alternatively a 0-10V input).
> There isn't an enable input. I do not need the reverse so it should be
> two parallel pins, one for forward and one for speed.
... snip

I found a manual here:
https://inverterdrive.com/file/Toshiba-VFS15-User-Manual

I usually first check the overview graphic which seems to be on page 
B-4. I see the F terminal which could just be shorted to common to 
activate it. The speed potentiometer is shown too. PWM could simulate 
that. I also see theRS485 connector. I did a search in the document for 
"485" and found page C-4, which shows some control options; terminal 
(relay), keypad, RS485 (Modbus?), CAN (cool), communication(what the 
heck?). Just below are some speed setting options. This should be a nice 
VFD.

A little farther down from B-4 are the I/O circuit options. Looking at 
the F entry, it basically says shorting the F terminal to CC will start 
forward rotation. You can use a parallel port pin to control a small 
solid state relay or opto-isolator. It just needs to tolerate 24 Volts 
on the output.

It looks like the VIA (voltage, input, analog?) is a speed input. The 
same parallel port pin to solid state relay or opto-isolator as F above 
may be used, except it only needs 10 Volt tolerence. Terminal PP is the 
10 Volt source (CC common isn't needed, most likely). The signal from 
the parallel port pin should use PWM or PDM.

If you have a BOB (Break Out Board), post a make/model and/or picture or 
other information. It may be useful for the above connections.

It looks like page D-3 is a good place to start VFD programing.

The above may be wrong or missing some information, so study the manual 
and decide for yourself what to do. I would get a mains input noise 
filter right of the bat, so you don't have to chase down weird issues 
while trying to learn how to use your VFD. Hmm... It looks like your VFD 
already has a built-in noise filter.


-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's, whats next?

[Todd Zuercher]

The tabs don't have to encompass the whole pyvcp window, only the items in the 
box that needs to change.  I can't guess how much load it may add to your puny 
little pi.  Can't imagine it would be a whole lot. 

Unfortunately I don't think pyvcp does dynamic anything (hence why the tabs 
hack to start with) including using anything other than a mouse click for 
selecting the tabs.

- Original Message -
From: "Gene Heskett" 
To: emc-users@lists.sourceforge.net
Sent: Thursday, February 16, 2017 10:56:17 AM
Subject: Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's,  
whats next?

Humm  When the detectors get here, so I can feed it a 5-pack of 
signals if the backgear lever is included, its possible that those 
signals might also be rigged in parallel with the mouse clicks that 
change the tabs, so the tab change would be automatic at initial run 
time. But it would be a tab switch for an after init time change.

But with 8 essentially duplicates of the xml code to draw them, would 
this not be a huge suckage on the pi's limited resources? Other than 
that, I don't have any objections.

I would need to set the tabs up to control 2 sets of 4 meters yadda, 
yadda. That would be 5 tab buttons total with the first one selecting 
which bank of 4 to select. So if backgear was engaged, the tabs would be 
labeled 5,6,7,8.  Or is that dynamic relabeling of the tabs even doable? 
I don't know.  Might have to define 8 tabs and only show the 4 currently 
applicable. More reading, thats for sure.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Unexpected move after Stop

[Sebastian Kuzminsky]

On 02/16/2017 09:01 AM, Marius Alksnys wrote:
>
>
> 02/16/2017 05:25 PM, Sebastian Kuzminsky rašė:
> ...
>> There were a couple of terrible "surprise move" bugs in 2.7.5 and 2.7.6.
>>   As far as we know these are all fixed in 2.7.7 and later.
>>
>> Which version of LinuxCNC were you running when you had this surprise
>> motion?  I really hope it was something older than 2.7.7!
>
> It was 2.7.8 and now 2.8.0-pre1-2846-g9e23976, and I can't find a way to
> offer an operator to stop the program in the middle. It just moves after
> stop. Every time.

That sounds frustrating, but it's great that it's super repeatable, 
that'll make it easier to find and debug.

I tried to reproduce the problem here this morning in 2.7, but could not 
get anything bad to happen.

Can you reproduce it in a sim config, and send a detailed recipe telling 
me how you reproduce it on your system?

If it's not reproducible in sim, the second best option is to post a 
complete copy of your config (along with the steps you take to reproduce 
the problem) and i'll try to whittle it down to something that i can 
reproduce locally.


-- 
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Unexpected move after Stop

[Marius Alksnys]

02/16/2017 05:25 PM, Sebastian Kuzminsky rašė:
...
> There were a couple of terrible "surprise move" bugs in 2.7.5 and 2.7.6.
>   As far as we know these are all fixed in 2.7.7 and later.
>
> Which version of LinuxCNC were you running when you had this surprise
> motion?  I really hope it was something older than 2.7.7!

It was 2.7.8 and now 2.8.0-pre1-2846-g9e23976, and I can't find a way to 
offer an operator to stop the program in the middle. It just moves after 
stop. Every time.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's, whats next?

[Gene Heskett]

On Thursday 16 February 2017 09:57:30 Todd Zuercher wrote:

> I thought that you were trying to make the pyvcp meter change scales. 
> My idea (and this still might be useful to you) was to have a tab for
> each of your gear settings.  In each tab you would have an RPM meter
> for the spindle that was scaled with the appropriate warning zones,
> LEDs... for that gear.  The main drawback I see to this set up is that
> it would not be automatic with your gear change, you'd still have to
> select the tab, when you select your gear.  But is that really that
> big of a deal on a manual gear changing home hobby machine?
>
Humm  When the detectors get here, so I can feed it a 5-pack of 
signals if the backgear lever is included, its possible that those 
signals might also be rigged in parallel with the mouse clicks that 
change the tabs, so the tab change would be automatic at initial run 
time. But it would be a tab switch for an after init time change.

But with 8 essentially duplicates of the xml code to draw them, would 
this not be a huge suckage on the pi's limited resources? Other than 
that, I don't have any objections.

I would need to set the tabs up to control 2 sets of 4 meters yadda, 
yadda. That would be 5 tab buttons total with the first one selecting 
which bank of 4 to select. So if backgear was engaged, the tabs would be 
labeled 5,6,7,8.  Or is that dynamic relabeling of the tabs even doable? 
I don't know.  Might have to define 8 tabs and only show the 4 currently 
applicable. More reading, thats for sure.


> - Original Message -
> From: "Gene Heskett" 
> To: emc-users@lists.sourceforge.net
> Sent: Thursday, February 16, 2017 1:34:10 AM
> Subject: Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the
> repo's,   whats next?
>
> On Thursday 16 February 2017 00:54:30 Todd Zuercher wrote:
> > You seem to have quickly dismissed my idea of using tabs in the
> > pyvcp window.  I had set up configs that used a pyvcp panel that had
> > a series of buttons for incrementally jogging the machine
> > coordinates. There were 4 tabs, one for jogging inches, tenths,
> > hundredths, and thousandths.  On each tab was an identical grid of
> > jogging buttons and a label for the increment.  It worked well and
> > looked good.  The main downside was it used 32 halui mdi pins for 8
> > buttons. sceenshot.
> > https://forum.linuxcnc.org/media/kunena/attachments/3190/error2.png
>
> Looks pretty good Todd, but thats not what I want to do. I want it to
> tell me when PI need to stop and change the belt to a different
> "gear". This can be done with some hal modules and 3 pyvcp leds.  The
> led's are already on the gui, and I'm waiting for mpja.com to send me
> some belt position sensors in the form of a 4 channel ir obstacle
> detector. Friday maybe. Depending on how they work, I'll get another
> and put it on the backgear lever so LCNC will then know exactly what
> gear its in.  If I ask for 1000 revs, it can't do that in backgear
> out, 1st gear on the belt as I have the vfd set for 150 Hz tops=800
> revs.  So I want it to tell me it needs a higher gear. There comes a
> point where I'd need a 5 horse motor, but them puppies be heavily gold
> plated whereas I have $25 each in the pair of 1 hp's I got from a
> local scrap dealer. I took a 3/4 single phase off it that weighs what
> these 2 do together.
>
> > - Original Message -
> > From: "Gene Heskett" 
> > To: emc-users@lists.sourceforge.net
> > Sent: Wednesday, February 15, 2017 9:38:15 PM
> > Subject: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the
> > repo's, whats next?
> >
> > Greetings guys;
> >
> > I just spent an hour, both on this machine,  and on the pi, trying
> > to make the one example gvcp-panel.test.ui we have, run. I can get a
> > tiny led out of it on this wheezy machine, but Glade 3+ on the pi
> > knows nothing of the widget creation commands in that file.  ,
> > HAL_LED, 95% of the file is an error report.
> >
> > So it looks like gtk2+ is officially shitcanned.
> >
> > Except all the /usr/lib/python2.7/gladevcp stuff is there on the pi,
> > I think:
> > ls =
> > calculator.glade  gladebuilder.pyc hal_filechooser.py
> > hal_lightbutton.py   hal_pythonplugin.py   __init__.py
> > offsetpage.glade   persistence.pyc
> > calculatorwidget.py   gladevcp-test.glade  hal_filechooser.pyc
> > hal_lightbutton.pyc  hal_pythonplugin.pyc  __init__.pyc
> > offsetpage_widget.py   speedcontrol.py
> > calculatorwidget.pyc  hal_actions.py   hal_graph.py
> > hal_mdihistory.pyhal_sourceview.py jogwheel.py
> > offsetpage_widget.pyc  speedcontrol.pyc
> > combi_dro.py  hal_actions.pyc  hal_graph.pyc
> > hal_mdihistory.pyc   hal_sourceview.pycjogwheel.pyc
> > offsetwidget.py tooledit_gtk.glade
> > combi_dro.pyc hal_bar.py   hal_gremlin_plus.py
> > hal_meter.py hal_widgets.pyled.py
> > offsetwidget.pyc   tooledit_widget.py
> > drowidget.py  hal_bar.pyc  

Re: [Emc-users] Unexpected move after Stop

[Sebastian Kuzminsky]

On 02/16/2017 07:32 AM, Marius Alksnys wrote:
> I can confirm the same on another 3 axis machine with trivial
> kinematics. After stopping or pause/stopping a program motion continues
> some straight line at programmed feedrate to some point and stops. The
> distance is big. This occurs every time, when paused in an arc motion
> and stopped after that. Two tools already broken..
>
> I found this as an already fixed "surprise move bug" in master:
> https://github.com/LinuxCNC/linuxcnc/commit/404be0fd8f6b6396f31943755db4b4754687d79b

There were a couple of terrible "surprise move" bugs in 2.7.5 and 2.7.6. 
  As far as we know these are all fixed in 2.7.7 and later.

Which version of LinuxCNC were you running when you had this surprise 
motion?  I really hope it was something older than 2.7.7!


> Then I installed master branch and get another errors - not being able
> to run any program with an error:
> emc/task/emctask.cc 397: interp_error: exception during generator call:
> TypeError: 'NoneType' object is not callable
>
> exception during generator call: TypeError: 'NoneType' object is not
> callable
>
>
> What would you recommend me to do?

If this problem occurs with 2.7.8, then please try reproduce the problem 
in a sim config.  Then post a tarball of the whole config directory and 
a gcode file and a set of steps the operator can take to reproduce the 
problem.


> Debug messages:
> Issuing EMC_TRAJ_LINEAR_MOVE --(  +220,+120,
> +0,105.936000,174.984000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
> +2,13.33,342.188909,1231.880073,+0,-1,)
> Motion id 24 took 0.082464 seconds.
> Outgoing motion id is 1108.
> Issuing EMC_TRAJ_LINEAR_MOVE --(  +220,+120,
> +0,105.047000,175.443000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
> +2,13.33,375.140935,1350.507367,+0,-1,)
> Issuing EMC_TASK_PLAN_PAUSE -- (  +510,+12,   +31,)
> Issuing EMC_TASK_ABORT --  (  +503,+12,   +32,)
> emc/task/emctask.cc 389: interp_error: bad number format (conversion
> failed) parsing ''
> bad number format (conversion failed) parsing ''
> Motion id 25 took 3.132175 seconds.
> Motion id 0 took 0.02 seconds.
> Outgoing motion id is 2114.
> Issuing EMC_TASK_PLAN_SYNCH -- (  +516,+12,+0,)
> Outgoing motion id is 2115.
> Issuing EMC_TRAJ_LINEAR_MOVE --(  +220,+120,
> +0,169.066000,226.898000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
> +2,13.33,342.896322,1234.426761,+0,-1,)
> Issuing EMC_TASK_SET_MODE --   (  +504,+16,   +33,+1,)
> Motion id 2115 took 5.132525 seconds.
> Motion id 0 took 0.02 seconds.
> Issuing EMC_TASK_PLAN_SYNCH -- (  +516,+12,+0,)
> can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the
> interpreter idle

Well that looks all kinds of broken.  I don't get that when I pause and 
then abort a linear move in 2.7.8 in sim/axis/axis.


-- 
Sebastian Kuzminsky

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Unexpected move after Stop

[Marius Alksnys]

This surprise move exists even in the latest master version.

I solved "exception during generator call: TypeError: 'NoneType' object 
is not callable" by deleting and making new python stdglue.py, remap.py 
nd toplevel.py files like it is written here: 
http://linuxcnc.org/docs/devel/html/remap/remap.html#_upgrading_an_existing_configuration_for_remapping

02/16/2017 04:32 PM, Marius Alksnys rašė:
> I can confirm the same on another 3 axis machine with trivial
> kinematics. After stopping or pause/stopping a program motion continues
> some straight line at programmed feedrate to some point and stops. The
> distance is big. This occurs every time, when paused in an arc motion
> and stopped after that. Two tools already broken..
>
> I found this as an already fixed "surprise move bug" in master:
> https://github.com/LinuxCNC/linuxcnc/commit/404be0fd8f6b6396f31943755db4b4754687d79b
>
> Then I installed master branch and get another errors - not being able
> to run any program with an error:
> emc/task/emctask.cc 397: interp_error: exception during generator call:
> TypeError: 'NoneType' object is not callable
>
> exception during generator call: TypeError: 'NoneType' object is not
> callable
>
>
> What would you recommend me to do?
>
> Info from v. 2.7.8 config:
> In G-code:
> G64 P0.05 Q0.001
>
> I use M6 tool change remap with subroutines. Two important lines in main
> INI file:
> [RS274NGC]
> ...
> REMAP=M6 modalgroup=6 prolog=change_prolog ngc=toolchange
> epilog=change_epilog
> ON_ABORT_COMMAND=O  call
> ...
> [TRAJ]
> AXES = 3
> COORDINATES = X Y Z
> LINEAR_UNITS = mm
> ANGULAR_UNITS = degree
> CYCLE_TIME = 0.010
> DEFAULT_LINEAR_VELOCITY = 50
> MAX_LINEAR_VELOCITY = 700
> NO_FORCE_HOMING = 0
> ARC_BLEND_ENABLE = 1
> ARC_BLEND_FALLBACK_ENABLE = 0
> ARC_BLEND_OPTIMIZATION_DEPTH = 100
> ARC_BLEND_GAP_CYCLES = 4
> ARC_BLEND_RAMP_FREQ = 100
>
> LinuxCNC/AXIS version 2.7.8
> 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux
>
> Debug messages:
> Issuing EMC_TRAJ_LINEAR_MOVE --(  +220,+120,
> +0,105.936000,174.984000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
> +2,13.33,342.188909,1231.880073,+0,-1,)
> Motion id 24 took 0.082464 seconds.
> Outgoing motion id is 1108.
> Issuing EMC_TRAJ_LINEAR_MOVE --(  +220,+120,
> +0,105.047000,175.443000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
> +2,13.33,375.140935,1350.507367,+0,-1,)
> Issuing EMC_TASK_PLAN_PAUSE -- (  +510,+12,   +31,)
> Issuing EMC_TASK_ABORT --  (  +503,+12,   +32,)
> emc/task/emctask.cc 389: interp_error: bad number format (conversion
> failed) parsing ''
> bad number format (conversion failed) parsing ''
> Motion id 25 took 3.132175 seconds.
> Motion id 0 took 0.02 seconds.
> Outgoing motion id is 2114.
> Issuing EMC_TASK_PLAN_SYNCH -- (  +516,+12,+0,)
> Outgoing motion id is 2115.
> Issuing EMC_TRAJ_LINEAR_MOVE --(  +220,+120,
> +0,169.066000,226.898000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
> +2,13.33,342.896322,1234.426761,+0,-1,)
> Issuing EMC_TASK_SET_MODE --   (  +504,+16,   +33,+1,)
> Motion id 2115 took 5.132525 seconds.
> Motion id 0 took 0.02 seconds.
> Issuing EMC_TASK_PLAN_SYNCH -- (  +516,+12,+0,)
> can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the
> interpreter idle
>
>
> 06/25/2016 08:35 PM, Tomaz T. rašė:
>>
>>
>>
>> I'm a bit confused what could cause unexpected move after pressing stop or 
>> pause->stop.
>> Here is print screen what happened: https://cdn.pbrd.co/images/1X2RCHL7.jpg
>> Recently I implemented manualtoolchange but the only thing I was modifying 
>> were subroutines ... not sure if there could be source of this issue?


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's, whats next?

[Todd Zuercher]

I thought that you were trying to make the pyvcp meter change scales.  My idea 
(and this still might be useful to you) was to have a tab for each of your gear 
settings.  In each tab you would have an RPM meter for the spindle that was 
scaled with the appropriate warning zones, LEDs... for that gear.  The main 
drawback I see to this set up is that it would not be automatic with your gear 
change, you'd still have to select the tab, when you select your gear.  But is 
that really that big of a deal on a manual gear changing home hobby machine?

- Original Message -
From: "Gene Heskett" 
To: emc-users@lists.sourceforge.net
Sent: Thursday, February 16, 2017 1:34:10 AM
Subject: Re: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the repo's,  
whats next?

On Thursday 16 February 2017 00:54:30 Todd Zuercher wrote:

> You seem to have quickly dismissed my idea of using tabs in the pyvcp
> window.  I had set up configs that used a pyvcp panel that had a
> series of buttons for incrementally jogging the machine coordinates. 
> There were 4 tabs, one for jogging inches, tenths, hundredths, and
> thousandths.  On each tab was an identical grid of jogging buttons and
> a label for the increment.  It worked well and looked good.  The main
> downside was it used 32 halui mdi pins for 8 buttons. sceenshot.
> https://forum.linuxcnc.org/media/kunena/attachments/3190/error2.png
>
>
Looks pretty good Todd, but thats not what I want to do. I want it to 
tell me when PI need to stop and change the belt to a different "gear".  
This can be done with some hal modules and 3 pyvcp leds.  The led's are 
already on the gui, and I'm waiting for mpja.com to send me some belt 
position sensors in the form of a 4 channel ir obstacle detector.  
Friday maybe. Depending on how they work, I'll get another and put it on 
the backgear lever so LCNC will then know exactly what gear its in.  If 
I ask for 1000 revs, it can't do that in backgear out, 1st gear on the 
belt as I have the vfd set for 150 Hz tops=800 revs.  So I want it to 
tell me it needs a higher gear. There comes a point where I'd need a 5 
horse motor, but them puppies be heavily gold plated whereas I have $25 
each in the pair of 1 hp's I got from a local scrap dealer. I took a 3/4 
single phase off it that weighs what these 2 do together.
> - Original Message -
> From: "Gene Heskett" 
> To: emc-users@lists.sourceforge.net
> Sent: Wednesday, February 15, 2017 9:38:15 PM
> Subject: [Emc-users] No gladevcp on a pi, no glade-gtk2 in the
> repo's,   whats next?
>
> Greetings guys;
>
> I just spent an hour, both on this machine,  and on the pi, trying to
> make the one example gvcp-panel.test.ui we have, run. I can get a tiny
> led out of it on this wheezy machine, but Glade 3+ on the pi knows
> nothing of the widget creation commands in that file.  ,
> HAL_LED, 95% of the file is an error report.
>
> So it looks like gtk2+ is officially shitcanned.
>
> Except all the /usr/lib/python2.7/gladevcp stuff is there on the pi, I
> think:
> ls =
> calculator.glade  gladebuilder.pyc hal_filechooser.py
> hal_lightbutton.py   hal_pythonplugin.py   __init__.py
> offsetpage.glade   persistence.pyc
> calculatorwidget.py   gladevcp-test.glade  hal_filechooser.pyc
> hal_lightbutton.pyc  hal_pythonplugin.pyc  __init__.pyc
> offsetpage_widget.py   speedcontrol.py
> calculatorwidget.pyc  hal_actions.py   hal_graph.py
> hal_mdihistory.pyhal_sourceview.py jogwheel.py
> offsetpage_widget.pyc  speedcontrol.pyc
> combi_dro.py  hal_actions.pyc  hal_graph.pyc
> hal_mdihistory.pyc   hal_sourceview.pycjogwheel.pyc 
> offsetwidget.py tooledit_gtk.glade
> combi_dro.pyc hal_bar.py   hal_gremlin_plus.py
> hal_meter.py hal_widgets.pyled.py
> offsetwidget.pyc   tooledit_widget.py
> drowidget.py  hal_bar.pyc  hal_gremlin_plus.pyc
> hal_meter.pychal_widgets.pyc   led.pyc
> overridewidget.py  tooledit_widget.pyc
> drowidget.pyc hal_dial.py  hal_gremlin.py
> hal_pyngcgui.py  iconview.py   makepins.py
> overridewidget.pyc xembed.py
> gladebuilder.py   hal_dial.pyc hal_gremlin.pyc
> hal_pyngcgui.pyc iconview.pyc  makepins.pyc 
> persistence.py xembed.pyc
>
> I did find a 3 yo msg with google that recommended setting up env vars
> with export for where it was, found the python-2.7 versions and
> exported that path, but if it helped I didn't/couldn't tell.
> glade-3.18.xx apparently can't use it.
>
> What do we do next? pyvcp I am told cannot do what I want.
>
> Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
Check out the vibrant tech community on one of the w

Re: [Emc-users] Unexpected move after Stop

[Marius Alksnys]

I can confirm the same on another 3 axis machine with trivial 
kinematics. After stopping or pause/stopping a program motion continues 
some straight line at programmed feedrate to some point and stops. The 
distance is big. This occurs every time, when paused in an arc motion 
and stopped after that. Two tools already broken..

I found this as an already fixed "surprise move bug" in master: 
https://github.com/LinuxCNC/linuxcnc/commit/404be0fd8f6b6396f31943755db4b4754687d79b

Then I installed master branch and get another errors - not being able 
to run any program with an error:
emc/task/emctask.cc 397: interp_error: exception during generator call: 
TypeError: 'NoneType' object is not callable

exception during generator call: TypeError: 'NoneType' object is not 
callable


What would you recommend me to do?

Info from v. 2.7.8 config:
In G-code:
G64 P0.05 Q0.001

I use M6 tool change remap with subroutines. Two important lines in main 
INI file:
[RS274NGC]
...
REMAP=M6 modalgroup=6 prolog=change_prolog ngc=toolchange 
epilog=change_epilog
ON_ABORT_COMMAND=O  call
...
[TRAJ]
AXES = 3
COORDINATES = X Y Z
LINEAR_UNITS = mm
ANGULAR_UNITS = degree
CYCLE_TIME = 0.010
DEFAULT_LINEAR_VELOCITY = 50
MAX_LINEAR_VELOCITY = 700
NO_FORCE_HOMING = 0
ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 0
ARC_BLEND_OPTIMIZATION_DEPTH = 100
ARC_BLEND_GAP_CYCLES = 4
ARC_BLEND_RAMP_FREQ = 100

LinuxCNC/AXIS version 2.7.8
3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux

Debug messages:
Issuing EMC_TRAJ_LINEAR_MOVE --  (  +220,+120, 
+0,105.936000,174.984000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
 
+2,13.33,342.188909,1231.880073,+0,-1,)
Motion id 24 took 0.082464 seconds.
Outgoing motion id is 1108.
Issuing EMC_TRAJ_LINEAR_MOVE --  (  +220,+120, 
+0,105.047000,175.443000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
 
+2,13.33,375.140935,1350.507367,+0,-1,)
Issuing EMC_TASK_PLAN_PAUSE --   (  +510,+12,   +31,)
Issuing EMC_TASK_ABORT --(  +503,+12,   +32,)
emc/task/emctask.cc 389: interp_error: bad number format (conversion 
failed) parsing ''
bad number format (conversion failed) parsing ''
Motion id 25 took 3.132175 seconds.
Motion id 0 took 0.02 seconds.
Outgoing motion id is 2114.
Issuing EMC_TASK_PLAN_SYNCH --   (  +516,+12,+0,)
Outgoing motion id is 2115.
Issuing EMC_TRAJ_LINEAR_MOVE --  (  +220,+120, 
+0,169.066000,226.898000,-401.414000,0.00,0.00,0.00,0.00,0.00,0.00,
 
+2,13.33,342.896322,1234.426761,+0,-1,)
Issuing EMC_TASK_SET_MODE -- (  +504,+16,   +33,+1,)
Motion id 2115 took 5.132525 seconds.
Motion id 0 took 0.02 seconds.
Issuing EMC_TASK_PLAN_SYNCH --   (  +516,+12,+0,)
can't do that (EMC_TRAJ_SET_TELEOP_ENABLE) in auto mode with the 
interpreter idle


06/25/2016 08:35 PM, Tomaz T. rašė:
>
>
>
> I'm a bit confused what could cause unexpected move after pressing stop or 
> pause->stop.
> Here is print screen what happened: https://cdn.pbrd.co/images/1X2RCHL7.jpg
> Recently I implemented manualtoolchange but the only thing I was modifying 
> were subroutines ... not sure if there could be source of this issue?


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] vfd compatibility

[Valerio Bellizzomi]

On Wed, 2017-02-15 at 14:06 -0800, Kirk Wallace wrote:
> On 02/15/2017 10:36 AM, Valerio Bellizzomi wrote:
> > On Wed, 2017-02-15 at 10:22 -0800, Kirk Wallace wrote:
> >> On 02/15/2017 09:25 AM, Valerio Bellizzomi wrote:
> >>> Hello,
> >>>
> >>> I have an Toshiba vfd which has a current signal input (max 20mA), is
> >>> that compatible with linuxcnc to be wired to S gcode command ?
> 
> 
> > I am not aware of any interface hardware , I thought to wire one
> > parallel pin to the vfd, but I might be wrong.
> >
> > suggestions?
> 
> If you reply with the Toshiba model number, we could give you better 
> information. Pictures and overview of your project would be even better.
> 
> Basic direction an speed control can be done with just a parallel port 
> and a few electronic parts. Here is an example:
> http://linuxcnc.org/docs/html/examples/spindle.html#_pwm_spindle_speed
> 
> The PWM bits create an analog signal using a digital parallel port pin 
> and switching it on/off in a way that effectively acts like an analog 
> signal. This would go to your VFD analog speed or frequency input. This 
> is only needed if you want LinuxCNC to control VFD speed. The example 
> shows the PWM signal being connected to the parallel port pin 9.
> 
> Sections 3 and 4 below the spindle section (2) connect the basic digital 
> signals to parallel port pins 14, 16, and 17.
> 
> Usually the VFD inputs are opto-isolators which are usually a floating 
> LED and current limit resistor circuit. Common parallel port buffer 
> boards are good for driving these inputs. A breakout board with 
> opto-isolators is not needed. A nice thing about parallel ports is that 
> add-on cards are cheap and you can add as many ports as your computer 
> slots can hold. The down side is that parallel ports are slow, so the 
> PWM signal will not have high resolution.
> 


the VFD is a Toshiba VFS15-4037PL-W, it has a Forward input, a Reverse
input, and a current speed input (and alternatively a 0-10V input).
There isn't an enable input. I do not need the reverse so it should be
two parallel pins, one for forward and one for speed.




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] vfd compatibility

[Valerio Bellizzomi]

On Thu, 2017-02-16 at 02:40 -0500, Gene Heskett wrote:
> On Thursday 16 February 2017 02:20:30 Valerio Bellizzomi wrote:
> 
> > On Wed, 2017-02-15 at 19:13 -0500, Gene Heskett wrote:
> > > On Wednesday 15 February 2017 15:12:17 Valerio Bellizzomi wrote:
> > > > On Wed, 2017-02-15 at 14:32 -0500, Gene Heskett wrote:
> > > > > On Wednesday 15 February 2017 14:13:17 Valerio Bellizzomi wrote:
> > > > > > On Wed, 2017-02-15 at 12:45 -0600, dragon wrote:
> > > > > > > The 20ma control circuit on the VFD is an analog control,
> > > > > > > where as the parallel port pin is a digital (on/off) signal.
> > > > > > > You will need some sort of hardware interface between the
> > > > > > > two to do a digital to analog conversion.
> > > > > >
> > > > > > is there a list of supported hardware, that I could buy on
> > > > > > ebay ? I was looking at
> > > > > > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Ha
> > > > > >rdwa re
> > > > > >
> > > > > > I have already 3 stepper drivers mounted in a metal box with
> > > > > > their power supply, I would need only a small interface for
> > > > > > the spindle.
> > > > >
> > > > > Using software stepping? I'd still use a pwmgen module in the
> > > > > computer to drive the vfd, but I'd put a SpinX1, from Mesa
> > > > > between them, for the noise isolation (vfd's are noisy
> > > > > electrically), and the control is quite linear. I would put the
> > > > > pwmgen in the PDMgen mode, see the man page as that removes the
> > > > > need to dither the pulse width because each step is fixed, the
> > > > > dither keeps it at the requested speed. But with PDM, you don't
> > > > > need the dither.  With SW pwmgens, I'd choose a refresh rate
> > > > > below the servothread by about half, the vfd shouldn't mind.
> > > >
> > > > I have checked out the mesa store, it is a problem for me that
> > > > they do not have paypal transactions among their choices for
> > > > payment, I do not own a credit card
> > > >
> > > > is there another way to purchase say a spinx1 or equivalent board
> > > > ?
> > >
> > > There are actually 2 web stores, one by Peter C. Wallace, out on the
> > > left coast, and Big John Thortons's site in southern Missouri. I am
> > > pretty sure either would take a check or money order. Big John ships
> > > the same day if he has it, 3 days to West Virginia is the worst he's
> > > done to me. I would imagine your money order would not be much
> > > slower.  Another day perhaps.
> > >
> > > Cheers, Gene Heskett
> >
> > Thanks Gene, I have already ordered one spinx1 here
> >
> >
> > http://mesaus.com/index.php?route=product/product&product_id=91
> >
> > I guess it will take a month or so as I live in Italy
> >
> Thats a bummer. Maurius L., or Andy, is there not someone on your side of 
> the pond that could get it there faster for when the next time comes up?
> 
> Cheers, Gene Heskett


I have to actually build the machine, so I can wait that long time,
meanwhile it will be hard metal work




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] vfd compatibility

[Peter Blodow]

Am 16.02.2017 08:40, schrieb Gene Heskett:
> On Thursday 16 February 2017 02:20:30 Valerio Bellizzomi wrote:
>
>> On Wed, 2017-02-15 at 19:13 -0500, Gene Heskett wrote:
>>> On Wednesday 15 February 2017 15:12:17 Valerio Bellizzomi wrote:
 On Wed, 2017-02-15 at 14:32 -0500, Gene Heskett wrote:
> On Wednesday 15 February 2017 14:13:17 Valerio Bellizzomi wrote:
>> On Wed, 2017-02-15 at 12:45 -0600, dragon wrote:
>>> The 20ma control circuit on the VFD is an analog control,
>>> where as the parallel port pin is a digital (on/off) signal.
>>> You will need some sort of hardware interface between the
>>> two to do a digital to analog conversion.
>> is there a list of supported hardware, that I could buy on
>> ebay ? I was looking at
>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_Supported_Ha
>> rdwa re
>>
>> I have already 3 stepper drivers mounted in a metal box with
>> their power supply, I would need only a small interface for
>> the spindle.
> Using software stepping? I'd still use a pwmgen module in the
> computer to drive the vfd, but I'd put a SpinX1, from Mesa
> between them, for the noise isolation (vfd's are noisy
> electrically), and the control is quite linear. I would put the
> pwmgen in the PDMgen mode, see the man page as that removes the
> need to dither the pulse width because each step is fixed, the
> dither keeps it at the requested speed. But with PDM, you don't
> need the dither.  With SW pwmgens, I'd choose a refresh rate
> below the servothread by about half, the vfd shouldn't mind.
 I have checked out the mesa store, it is a problem for me that
 they do not have paypal transactions among their choices for
 payment, I do not own a credit card

 is there another way to purchase say a spinx1 or equivalent board
 ?
>>> There are actually 2 web stores, one by Peter C. Wallace, out on the
>>> left coast, and Big John Thortons's site in southern Missouri. I am
>>> pretty sure either would take a check or money order. Big John ships
>>> the same day if he has it, 3 days to West Virginia is the worst he's
>>> done to me. I would imagine your money order would not be much
>>> slower.  Another day perhaps.
>>>
>>> Cheers, Gene Heskett
>> Thanks Gene, I have already ordered one spinx1 here
>>
>>
>> http://mesaus.com/index.php?route=product/product&product_id=91
>>
>> I guess it will take a month or so as I live in Italy
>>
> Thats a bummer. Maurius L., or Andy, is there not someone on your side of
> the pond that could get it there faster for when the next time comes up?
>
> Cheers, Gene Heskett
There used to be an internet shop in southern Germany, I forgot the 
address. That's EU, so shipping would last a few days at maximum. PCW 
should know, for he provided it to me some years ago.

Peter

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users