Re: [Emc-users] I put some pix up. See the GO704-pix link on my front page below.

[Gene Heskett]

On Tuesday 13 October 2015 13:56:41 Billy Huddleston wrote:

> I've got to ask.. What exactly is this and what is it for?
>
> http://geneslinuxbox.net:6309/gene/GO704-pix/gauge-drive-sliding-coupl
>ing.jpg
>
> ??

Shade tree engineering, a long and proud history for an old Iowa farm kid 
like me.

Reason?  The frame of that, salvaged from an old paper shredder, 
precludes putting the axis of that gear dead inline with the piano hinge 
the locator bar swings on.  And because I have a strong o-ring across a 
couple screws on the back of the hinge, pulling the end play out of the 
hinge with about ba 10 lb pull, I found that 2 things were happening.

1, the plastic hose was pushing against o-rings pull and screwing up the 
repeatability of the x asis detection.  Or 2, it was pulling itself off 
the gear when the jig was open.  So I milled a piece of 1/2" copper pipe 
about 3/4" long with 8 slots at 45 degree intervals, making the slots 
about 90 thou wide & .3" deep, as close as I can get to the 3 jaw on my 
cheap rotary table without the side of the spindle dragging on a chuck 
jaw.  Then bent them inward to engage the gullys of the 8 tooth gear.  
It freely slides endways on the gear as it opens and closes the locator 
bar.  Tied via hal to the "mist" button on the left panel of the axis 
gui I use, feeding the 5i25's P2 pin 17.

By the same token, a charge pump is running at 1/2 servo-thread rate, and 
the "flood" checkbox enables it via an and2 to drive a pump detector, 
watching the 5i25's P2-pin 16, which in turn turns on a transistor and 
that pulls in a DPDT icecube relay wired in parallel to start and stop 
the vacuum.  The added complexity of using the and2 in the hal file 
allows me to add more stuff to the mix.

But I haven't figured out how to get it to select a good board off the 
pile, take it over to the chop saw, cut it to length, and bring it back 
& mount it on the mill.  Yet... ;-]  First off, no robot I've seen 
walking around could negotiate that packrat built midden heap I loosely 
call a garage. :-[

> On 10/13/2015 09:25 AM, Gene Heskett wrote:
> > On Tuesday 13 October 2015 06:43:51 John Thornton wrote:
> >> You must be a fan of Rube Goldberg! I love the gauge thingy... not
> >> being an electronics genius like you I would have drilled the
> >> bottom of the holding thingy for some pins that fit the slots in
> >> the table to register the fixture in the Y axis
> >
> > I glued some legs on the ends that fit the T slots. I miss set them,
> > probably moved on the glue film when I tightened the screw so the
> > runout in the x direction is about 3 thou. They also fit the T-slot
> > too tight so it should be fixable. I just need to find my round
> > tuit. But I'd have to put a dial on the head and sweep the x,
> > measuring the closed bar, to figure out which leg to sand on.  Until
> > then, its close enough for wood.
> >
> >> then put a dowel in the spindle and
> >> move to - half the dowel diameter and slide the fixture up to the
> >> dowel. Then I would make a template like a L with pin holes and put
> >> that into the fixture and slide the part up to the L to set the X
> >> and Y of the part the same place every time. The remove the setup
> >> guide and machine away. But your way looks more fun.
> >
> > The x stopper is on the left, about 3/8" high, screwed and glued, so
> > it doesn't move.  The end of it adjacent to a finger on the board
> > has of course been machined away by the mill coming down the side of
> > the board, shaving it a thou or so. But I felt I had to make it
> > gcode controllable as I was losing track of the number of times I
> > had to reach over an flip it manually to keep the bar from being
> > carved up as the head was descending.  Walking to the far side of
> > the machine and bending over to turn on the vacuum was also a PIMB*.
> > :(
> >
> > Because this machine is more rigid, I've had to adjust the mills
> > diameter in the software to re-establish the glue line fit.  Or this
> > mill has less x backlash that the small one with its teeny ball
> > screws.  Needs bigger balls in the x screw, its about 1.6 thou.  On
> > the small mill, I had to tell the software the mill was only .243 in
> > diameter, effectively making it cut deeper.  On this one the same
> > glue fit is around .247"
> >
> > Anyway, the target is to set and clamp the board, sit down and hit r
> > until its time to change the tool or turn the board over. Rinse &
> > repeat for the other end of the board, then get some exercise
> > cutting the next board. And because the roundover bit is about 3/4"
> > shorter than the mill, I either need to fit collars to both bits, or
> > buy another R8-ER20 adaptor so the whole thing gets changed when its
> > tool changing time and I can know the stickout difference. 
> > Presently I have to probe both tools.
> >
> > In either case, my spindle pin brake needs something to hold it in
> > while my hand is busy catching the tool or adapter. I made it with a

Re: [Emc-users] LCNC fussing when it should not

[Gene Heskett]

On Tuesday 13 October 2015 12:46:56 Todd Zuercher wrote:

> Maybe this might be useful?
> http://linuxcnc.org/docs/html/remap/structure.html#sec:Adding-Predefin
>ed-Named-Parameters

It might be at some point, but I don't think this is it.  This reds like 
it involves a source code pull and build.  While I've built several 
hundred tarballs over the years, methinks there be hungry dragons in 
waiting if I tried to build LCNC.

Thanks for the suggestion though Todd, its yet another way to skin that 
famous cat.

Adding more vars to the variable.txt file, once LCNC has seen them once, 
seems to be working well. It has brought its own problems, largely with 
my math, and I was just forced to reconfigure the Z homing setup to make 
some room between home and some positive values for Z, up to about .2".  
That means I have to recalibrate about a dozen vars in my code, but its 
22:00 and I'm beat. I did get the non-roundover part doing beautifully 
fitting joints that are within a couple thou of perfectly symetrical 
when one of the 2 test boards is flipped top to bottom.  A prerequisit 
to being able to flip the board over and do the roundover on both sides.

So for the last 4 hours, I cooked for us, started the dishwasher, and 
worked on the roundover code sections.  Running about 20 thou above the 
board for exercise, the left edge, end edge, and the inside the finger 
edge are pretty close, but its overshooting the right edge around 1/4", 
doing a great job of carving air at 2400 revs. Something wrong with the 
x run distance calcs in the right corner subroutine.  That, and the left 
corner subroutine needs run straight up another 50 thou, with a 
corresponding reduction in the radius of the 90 degree curve.  I need to 
make it too small, put it into the wood, and expand it till it traces 
what the 1/4" mill left, which is supposed to be a 1/8" radius corner, 
but looking at it, it looks small.  But I am about burned out and 
tomorrow is another day.

Thanks Todd.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rookie question - what to get to run LinCNC easily/inexpensively

[alex chiosso]

Hi Claude.
Did you tried to use a PS2 mouse and keyboard so you can disable the usb
ports and see if the latency spikes are still there ?

Regards

Alex

On Tue, Oct 13, 2015 at 8:05 AM, Karlsson & Wang <
nicklas.karls...@karlssonwang.se> wrote:

> > ...
> > Have you guys found anything in particular that might cause latency
> spikes
> > that I'm seeing? I installed 2.7-Wheezy from the pre-built live/install
> ISO
> > and I'm using the onboard video. No extra hardware besides a USB mouse
> and
> > keyboard.
> > Also, I'm planning to get a Mesa 5i25 so maybe the latency isn't a
> problem?
> >
> > regards,
> > - Claude
>
> I have been thinking about moving the control loop from the PC to the
> motor driver and then latency would be less of a problem. The motor driver
> I use run a control loop at 40kHz while linuxcnc position control loop run
> at 1kHz but with position control in motor driver and linear interpolation
> I guess 100Hz for linuxcnc control loop would be enough.
>
> Nicklas Karlsson
>
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] LCNC fussing when it should not

[Gene Heskett]

Greetings all;

Trying to take advantage of the fact that named vars remain in memory and 
are accessable from the next program loaded, I added some code to this 
blanket-chest3.ngc to do exactly that, allowing me to make use of a 
routine that is run immediately after homing, and which returns a set of 
offsets that I should be able to add to the "seed" values in my code, 
and which will then propagate thru my code, doing effectively what the 
G10 L2 Pn fixes were doing, and which correct the G55 mapping. This will 
remove the need for the use of a G55 map.

Those values in those named variables DO EXIST after having run this 
preliminary calibration routine, and then loading a blanket-chest.ngc 
from which those functions have been commented away. I can from the MDI 
command line, after loading the real code, do a 
(debug,jig_x=#<_jig_x>) or y or x, and see that they are perfectly 
preserved.

But LCNC won't process the code, says they don't exist. And I can't think 
of a way to create them without also destroying the values they contain.

Workaround(s)?  I did in fact do exactly this a couple times several 
years ago, perhaps in the 2.4.x era.  Perhaps saving them in a #5xxx 
location might work, but I've no clue which ones?  Humm, since I will 
not be using G55, perhaps in the G55's UVW locations?

Yes, its true, I can find a corner that didn't exist when I entered the 
room, and paint myself into it. ;-)

Thanks folks.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] I put some pix up. See the GO704-pix link on my front page below.

[John Thornton]

You must be a fan of Rube Goldberg! I love the gauge thingy... not being 
an electronics genius like you I would have drilled the bottom of the 
holding thingy for some pins that fit the slots in the table to register 
the fixture in the Y axis then put a dowel in the spindle and move to - 
half the dowel diameter and slide the fixture up to the dowel. Then I 
would make a template like a L with pin holes and put that into the 
fixture and slide the part up to the L to set the X and Y of the part 
the same place every time. The remove the setup guide and machine away. 
But your way looks more fun.

JT

On 10/12/2015 9:17 PM, Gene Heskett wrote:
> Yeah, its a midden heap, but its actually carving stuff.
>
> Cheers, Gene Heskett


--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] I put some pix up. See the GO704-pix link on my front page below.

[Gene Heskett]

On Tuesday 13 October 2015 06:43:51 John Thornton wrote:

> You must be a fan of Rube Goldberg! I love the gauge thingy... not
> being an electronics genius like you I would have drilled the bottom
> of the holding thingy for some pins that fit the slots in the table to
> register the fixture in the Y axis 

I glued some legs on the ends that fit the T slots. I miss set them, 
probably moved on the glue film when I tightened the screw so the runout 
in the x direction is about 3 thou. They also fit the T-slot too tight 
so it should be fixable. I just need to find my round tuit. But I'd have 
to put a dial on the head and sweep the x, measuring the closed bar, to 
figure out which leg to sand on.  Until then, its close enough for wood.

> then put a dowel in the spindle and 
> move to - half the dowel diameter and slide the fixture up to the
> dowel. Then I would make a template like a L with pin holes and put
> that into the fixture and slide the part up to the L to set the X and
> Y of the part the same place every time. The remove the setup guide
> and machine away. But your way looks more fun.

The x stopper is on the left, about 3/8" high, screwed and glued, so it 
doesn't move.  The end of it adjacent to a finger on the board has of 
course been machined away by the mill coming down the side of the board, 
shaving it a thou or so. But I felt I had to make it gcode controllable 
as I was losing track of the number of times I had to reach over an flip 
it manually to keep the bar from being carved up as the head was 
descending.  Walking to the far side of the machine and bending over to 
turn on the vacuum was also a PIMB*. :(

Because this machine is more rigid, I've had to adjust the mills diameter 
in the software to re-establish the glue line fit.  Or this mill has 
less x backlash that the small one with its teeny ball screws.  Needs 
bigger balls in the x screw, its about 1.6 thou.  On the small mill, I 
had to tell the software the mill was only .243 in diameter, effectively 
making it cut deeper.  On this one the same glue fit is around .247"

Anyway, the target is to set and clamp the board, sit down and hit r 
until its time to change the tool or turn the board over. Rinse & repeat 
for the other end of the board, then get some exercise cutting the next 
board. And because the roundover bit is about 3/4" shorter than the 
mill, I either need to fit collars to both bits, or buy another R8-ER20 
adaptor so the whole thing gets changed when its tool changing time and 
I can know the stickout difference.  Presently I have to probe both 
tools.

In either case, my spindle pin brake needs something to hold it in while 
my hand is busy catching the tool or adapter. I made it with a retractor 
spring as its not nice on things to try & start the spindle when its 
locked.

*PIMB pain in my back.

Thanks John.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Gene Heskett]

On Tuesday 13 October 2015 08:40:42 andy pugh wrote:

> On 13 October 2015 at 13:27, Todd  Zuercher
>
>  wrote:
> > What if you tried "global" named parameters?
> > #<_name> vs #
>
> They are program-global, not system-global.
> I think persistent numbered parameters are the way to go.
> http://linuxcnc.org/docs/html/gcode/overview.html#sub:numbered-paramet
>ers
>
> Any numbers you add to the .var file become new persistent parameters.

So I could start at #5602 and add 4 more params, #5603-4-5 and that would 
be kosher?  The current one ends at #5390, so I'd assume 5391-2-3-4 
could be added.  Kewl.  But what happens when another table is added by 
a later LCNC update?  I'll see if it will buy the 5602 with its huge gap 
in numbers.

Thanks Andy.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Gene Heskett]

On Tuesday 13 October 2015 07:29:10 andy pugh wrote:

> On 13 October 2015 at 10:36, Gene Heskett  wrote:
> > Trying to take advantage of the fact that named vars remain in
> > memory and are accessable from the next program loaded, I added some
> > code to this blanket-chest3.ngc to do exactly that,
>
> It may be that that is the case, but it isn't intentional. ie, this
> falls into the "undefined behaviour" area of G-code.

IMO when it encounters such a reference, it ought to compare it to the 
famous Amigados "deadbeef" string, which is what it used to detect out 
of bounds memory accesses. If its not, then whatever it is is valid.  
But linux has never poisoned memory that way, hasn't had to as it has a 
good memory manager.

> If you want a rather crazy way to do this you could write to G-code
> analogue outputs and read from analogue inputs, and loop them together
> in HAL.

Sounds like it would be usable.  Example?

> A better way would be to add some new persistent _numerical_
> parameters to the vars file. Those should then always exist.

And how would one go about that?  I thought of opening a probe file, but 
I have no clue how to extract the data in a form useful for this.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Gene Heskett]

On Tuesday 13 October 2015 08:27:33 Todd Zuercher wrote:

> What if you tried "global" named parameters?
> #<_name> vs #
>
These are almost all global definitions, Todd:
#<_jig_x> style.  The only place I use # locals is in a subroutine 
that may modify a value and I don't want that to propagate back to the 
main function.

Thanks Todd.

> - Original Message -
> From: "Gene Heskett" 
> To: "Enhanced Machine Controller (EMC)"
>  Sent: Tuesday, October 13, 2015
> 5:36:44 AM
> Subject: [Emc-users] LCNC fussing when it should not
>
> Greetings all;
>
> Trying to take advantage of the fact that named vars remain in memory
> and are accessable from the next program loaded, I added some code to
> this blanket-chest3.ngc to do exactly that, allowing me to make use of
> a routine that is run immediately after homing, and which returns a
> set of offsets that I should be able to add to the "seed" values in my
> code, and which will then propagate thru my code, doing effectively
> what the G10 L2 Pn fixes were doing, and which correct the G55
> mapping. This will remove the need for the use of a G55 map.
>
> Those values in those named variables DO EXIST after having run this
> preliminary calibration routine, and then loading a blanket-chest.ngc
> from which those functions have been commented away. I can from the
> MDI command line, after loading the real code, do a
> (debug,jig_x=#<_jig_x>) or y or x, and see that they are perfectly
> preserved.
>
> But LCNC won't process the code, says they don't exist. And I can't
> think of a way to create them without also destroying the values they
> contain.
>
> Workaround(s)?  I did in fact do exactly this a couple times several
> years ago, perhaps in the 2.4.x era.  Perhaps saving them in a #5xxx
> location might work, but I've no clue which ones?  Humm, since I will
> not be using G55, perhaps in the G55's UVW locations?
>
> Yes, its true, I can find a corner that didn't exist when I entered
> the room, and paint myself into it. ;-)
>
> Thanks folks.
>
> 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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Todd Zuercher]

Sorry, never mind, it looks like you already were.

- Original Message -
From: "Todd Zuercher" 
To: "Enhanced Machine Controller (EMC)" 
Sent: Tuesday, October 13, 2015 8:27:33 AM
Subject: Re: [Emc-users] LCNC fussing when it should not

What if you tried "global" named parameters?
#<_name> vs #

- Original Message -
From: "Gene Heskett" 
To: "Enhanced Machine Controller (EMC)" 
Sent: Tuesday, October 13, 2015 5:36:44 AM
Subject: [Emc-users] LCNC fussing when it should not

Greetings all;

Trying to take advantage of the fact that named vars remain in memory and 
are accessable from the next program loaded, I added some code to this 
blanket-chest3.ngc to do exactly that, allowing me to make use of a 
routine that is run immediately after homing, and which returns a set of 
offsets that I should be able to add to the "seed" values in my code, 
and which will then propagate thru my code, doing effectively what the 
G10 L2 Pn fixes were doing, and which correct the G55 mapping. This will 
remove the need for the use of a G55 map.

Those values in those named variables DO EXIST after having run this 
preliminary calibration routine, and then loading a blanket-chest.ngc 
from which those functions have been commented away. I can from the MDI 
command line, after loading the real code, do a 
(debug,jig_x=#<_jig_x>) or y or x, and see that they are perfectly 
preserved.

But LCNC won't process the code, says they don't exist. And I can't think 
of a way to create them without also destroying the values they contain.

Workaround(s)?  I did in fact do exactly this a couple times several 
years ago, perhaps in the 2.4.x era.  Perhaps saving them in a #5xxx 
location might work, but I've no clue which ones?  Humm, since I will 
not be using G55, perhaps in the G55's UVW locations?

Yes, its true, I can find a corner that didn't exist when I entered the 
room, and paint myself into it. ;-)

Thanks folks.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Todd Zuercher]

What if you tried "global" named parameters?
#<_name> vs #

- Original Message -
From: "Gene Heskett" 
To: "Enhanced Machine Controller (EMC)" 
Sent: Tuesday, October 13, 2015 5:36:44 AM
Subject: [Emc-users] LCNC fussing when it should not

Greetings all;

Trying to take advantage of the fact that named vars remain in memory and 
are accessable from the next program loaded, I added some code to this 
blanket-chest3.ngc to do exactly that, allowing me to make use of a 
routine that is run immediately after homing, and which returns a set of 
offsets that I should be able to add to the "seed" values in my code, 
and which will then propagate thru my code, doing effectively what the 
G10 L2 Pn fixes were doing, and which correct the G55 mapping. This will 
remove the need for the use of a G55 map.

Those values in those named variables DO EXIST after having run this 
preliminary calibration routine, and then loading a blanket-chest.ngc 
from which those functions have been commented away. I can from the MDI 
command line, after loading the real code, do a 
(debug,jig_x=#<_jig_x>) or y or x, and see that they are perfectly 
preserved.

But LCNC won't process the code, says they don't exist. And I can't think 
of a way to create them without also destroying the values they contain.

Workaround(s)?  I did in fact do exactly this a couple times several 
years ago, perhaps in the 2.4.x era.  Perhaps saving them in a #5xxx 
location might work, but I've no clue which ones?  Humm, since I will 
not be using G55, perhaps in the G55's UVW locations?

Yes, its true, I can find a corner that didn't exist when I entered the 
room, and paint myself into it. ;-)

Thanks folks.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[andy pugh]

On 13 October 2015 at 13:27, Todd  Zuercher
 wrote:
> What if you tried "global" named parameters?
> #<_name> vs #

They are program-global, not system-global.
I think persistent numbered parameters are the way to go.
http://linuxcnc.org/docs/html/gcode/overview.html#sub:numbered-parameters

Any numbers you add to the .var file become new persistent parameters.


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[andy pugh]

On 13 October 2015 at 10:36, Gene Heskett  wrote:
> Trying to take advantage of the fact that named vars remain in memory and
> are accessable from the next program loaded, I added some code to this
> blanket-chest3.ngc to do exactly that,

It may be that that is the case, but it isn't intentional. ie, this
falls into the "undefined behaviour" area of G-code.

If you want a rather crazy way to do this you could write to G-code
analogue outputs and read from analogue inputs, and loop them together
in HAL.

A better way would be to add some new persistent _numerical_
parameters to the vars file. Those should then always exist.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Gene Heskett]

On Tuesday 13 October 2015 08:40:42 andy pugh wrote:

> On 13 October 2015 at 13:27, Todd  Zuercher
>
>  wrote:
> > What if you tried "global" named parameters?
> > #<_name> vs #
>
> They are program-global, not system-global.
> I think persistent numbered parameters are the way to go.
> http://linuxcnc.org/docs/html/gcode/overview.html#sub:numbered-paramet
>ers
>
> Any numbers you add to the .var file become new persistent parameters.

So after re-reading that again, I just added 10, 4990-4999 to that file, 
and re-wrote the code to use them.

Not tested yet.  I'll use the first 3 for xyz with a 1/4" mill, and the 
next one for a routine that measures the stick diff for the roundover 
tool.  That can even be a separate .ngc utility because changing tools 
mid code every time is a PIMA.

Kewl idea Andy, many thanks. I may yet be off to the races and carving 
good wood instead of white pine test kindling. I have been stumbling 
over this pile of mahogany long enough.  Its height needs to be reduced.  
To zero.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Gene Heskett]

On Tuesday 13 October 2015 10:20:07 Gene Heskett wrote:

> On Tuesday 13 October 2015 08:40:42 andy pugh wrote:
> > On 13 October 2015 at 13:27, Todd  Zuercher
> >
> >  wrote:
> > > What if you tried "global" named parameters?
> > > #<_name> vs #
> >
> > They are program-global, not system-global.
> > I think persistent numbered parameters are the way to go.
> > http://linuxcnc.org/docs/html/gcode/overview.html#sub:numbered-param
> >et ers
> >
> > Any numbers you add to the .var file become new persistent
> > parameters.
>
> So after re-reading that again, I just added 10, 4990-4999 to that
> file, and re-wrote the code to use them.

But it refuses to run, something about number out of range? So I came 
back in here to send this, tried it from here, and it worked, must have 
had to reinitialize for the added stuff at 4990 on.  And now its all 
working.  And I am going to use that to send a switch to the calibrate 
routine, so that I can re-run it as a subroutine file after I do a tool 
change, to switch it to use the pointed tool target, a separate piece of 
PCB contact stuck to the gauge bar, to find the stickout difference.

This is getting better all the time folks. ;-)  Now I need to find a 
missing decimal point in a z calc, it thinks the described path is 192+ 
inches tall. But thats my problem to solve. :)

> Not tested yet.  I'll use the first 3 for xyz with a 1/4" mill, and
> the next one for a routine that measures the stick diff for the
> roundover tool.  That can even be a separate .ngc utility because
> changing tools mid code every time is a PIMA.
>
> Kewl idea Andy, many thanks. I may yet be off to the races and carving
> good wood instead of white pine test kindling. I have been stumbling
> over this pile of mahogany long enough.  Its height needs to be
> reduced. To zero.
>
> 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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Rookie question - what to get to run LinCNC easily/inexpensively

[Claude Zervas]

Thanks Alex, I haven't tried that yet but I will (unfortunately I threw out
my old PS2 keyboard and mouse a while back).
- Claude

On Tue, Oct 13, 2015 at 12:27 AM, alex chiosso  wrote:

> Hi Claude.
> Did you tried to use a PS2 mouse and keyboard so you can disable the usb
> ports and see if the latency spikes are still there ?
>
> Regards
>
> Alex
>
> On Tue, Oct 13, 2015 at 8:05 AM, Karlsson & Wang <
> nicklas.karls...@karlssonwang.se> wrote:
>
> > > ...
> > > Have you guys found anything in particular that might cause latency
> > spikes
> > > that I'm seeing? I installed 2.7-Wheezy from the pre-built live/install
> > ISO
> > > and I'm using the onboard video. No extra hardware besides a USB mouse
> > and
> > > keyboard.
> > > Also, I'm planning to get a Mesa 5i25 so maybe the latency isn't a
> > problem?
> > >
> > > regards,
> > > - Claude
> >
> > I have been thinking about moving the control loop from the PC to the
> > motor driver and then latency would be less of a problem. The motor
> driver
> > I use run a control loop at 40kHz while linuxcnc position control loop
> run
> > at 1kHz but with position control in motor driver and linear
> interpolation
> > I guess 100Hz for linuxcnc control loop would be enough.
> >
> > Nicklas Karlsson
> >
> >
> >
> --
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] LCNC fussing when it should not

[Todd Zuercher]

Maybe this might be useful?
http://linuxcnc.org/docs/html/remap/structure.html#sec:Adding-Predefined-Named-Parameters

- Original Message -
From: "Gene Heskett" 
To: emc-users@lists.sourceforge.net
Sent: Tuesday, October 13, 2015 9:34:08 AM
Subject: Re: [Emc-users] LCNC fussing when it should not

On Tuesday 13 October 2015 07:29:10 andy pugh wrote:

> On 13 October 2015 at 10:36, Gene Heskett  wrote:
> > Trying to take advantage of the fact that named vars remain in
> > memory and are accessable from the next program loaded, I added some
> > code to this blanket-chest3.ngc to do exactly that,
>
> It may be that that is the case, but it isn't intentional. ie, this
> falls into the "undefined behaviour" area of G-code.

IMO when it encounters such a reference, it ought to compare it to the 
famous Amigados "deadbeef" string, which is what it used to detect out 
of bounds memory accesses. If its not, then whatever it is is valid.  
But linux has never poisoned memory that way, hasn't had to as it has a 
good memory manager.

> If you want a rather crazy way to do this you could write to G-code
> analogue outputs and read from analogue inputs, and loop them together
> in HAL.

Sounds like it would be usable.  Example?

> A better way would be to add some new persistent _numerical_
> parameters to the vars file. Those should then always exist.

And how would one go about that?  I thought of opening a probe file, but 
I have no clue how to extract the data in a form useful for this.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] I put some pix up. See the GO704-pix link on my front page below.

[Billy Huddleston]

I've got to ask.. What exactly is this and what is it for?

http://geneslinuxbox.net:6309/gene/GO704-pix/gauge-drive-sliding-coupling.jpg

??

On 10/13/2015 09:25 AM, Gene Heskett wrote:
> On Tuesday 13 October 2015 06:43:51 John Thornton wrote:
>
>> You must be a fan of Rube Goldberg! I love the gauge thingy... not
>> being an electronics genius like you I would have drilled the bottom
>> of the holding thingy for some pins that fit the slots in the table to
>> register the fixture in the Y axis
> I glued some legs on the ends that fit the T slots. I miss set them,
> probably moved on the glue film when I tightened the screw so the runout
> in the x direction is about 3 thou. They also fit the T-slot too tight
> so it should be fixable. I just need to find my round tuit. But I'd have
> to put a dial on the head and sweep the x, measuring the closed bar, to
> figure out which leg to sand on.  Until then, its close enough for wood.
>
>> then put a dowel in the spindle and
>> move to - half the dowel diameter and slide the fixture up to the
>> dowel. Then I would make a template like a L with pin holes and put
>> that into the fixture and slide the part up to the L to set the X and
>> Y of the part the same place every time. The remove the setup guide
>> and machine away. But your way looks more fun.
> The x stopper is on the left, about 3/8" high, screwed and glued, so it
> doesn't move.  The end of it adjacent to a finger on the board has of
> course been machined away by the mill coming down the side of the board,
> shaving it a thou or so. But I felt I had to make it gcode controllable
> as I was losing track of the number of times I had to reach over an flip
> it manually to keep the bar from being carved up as the head was
> descending.  Walking to the far side of the machine and bending over to
> turn on the vacuum was also a PIMB*. :(
>
> Because this machine is more rigid, I've had to adjust the mills diameter
> in the software to re-establish the glue line fit.  Or this mill has
> less x backlash that the small one with its teeny ball screws.  Needs
> bigger balls in the x screw, its about 1.6 thou.  On the small mill, I
> had to tell the software the mill was only .243 in diameter, effectively
> making it cut deeper.  On this one the same glue fit is around .247"
>
> Anyway, the target is to set and clamp the board, sit down and hit r
> until its time to change the tool or turn the board over. Rinse & repeat
> for the other end of the board, then get some exercise cutting the next
> board. And because the roundover bit is about 3/4" shorter than the
> mill, I either need to fit collars to both bits, or buy another R8-ER20
> adaptor so the whole thing gets changed when its tool changing time and
> I can know the stickout difference.  Presently I have to probe both
> tools.
>
> In either case, my spindle pin brake needs something to hold it in while
> my hand is busy catching the tool or adapter. I made it with a retractor
> spring as its not nice on things to try & start the spindle when its
> locked.
>
> *PIMB pain in my back.
>
> Thanks John.
>
> Cheers, Gene Heskett

-- 
Billy Huddleston Inner Vision

*William Huddleston
Inner Vision Development Corp*
Office: 865.560.2752
Fax: 865.560.2703

http://www.ivdc.com
*Development and Consulting... Simplified.*

 
 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Hostmot2 (Use two cards)

[Jeff Epler]

On Mon, Oct 12, 2015 at 01:07:42PM +0100, andy pugh wrote:
> On 12 October 2015 at 03:37, Jeff Epler  wrote:
> > loadrt hm2_eth config="num_encoders=1 num_pwmgens=1 num_stepgens=1 
> > enable_raw=1,enable_raw=1" 
> > board_ip=192.168.1.123,192.168.1.122,192.168.1.121
> 
> Does HAL support continuation lines? Some of the parameter lists are
> getting very unwieldy.

No, but the underdocumented option to use .tcl files for hal
configuration does.

Jeff

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Is the Linuxcnc Web site ok?

[Sebastian Kuzminsky]

Something's gone wrong with the website and our hosting provider
(Dreamcast) has disabled our site.  Our IT specialists have been called
home from vacation and injected with caffeine for a heroic,
around-the-clock debugging effort.

Stay tuned for more as this breaking story develops.


On 10/13/2015 05:55 PM, Dave Cole wrote:
> 
>   I just got this:
> 
> 
>   Forbidden
> 
> You don't have permission to access / on this server.
> 
> Additionally, a 403 Forbidden error was encountered while trying to use 
> an ErrorDocument to handle the request.
> 
> 
> 
> On 10/13/2015 7:49 PM, jrmitchellj . wrote:
>> I am getting "forbiden" message when I try to connect to it.
>> It worked fine earlier today.
>>
>> Ray
>> On Aug 26, 2015 12:50 AM, "Marius Liebenberg" 
>> wrote:
>>
>>> I changed the input spindle frequency to 200Hz and fixed the scaling.
>>> The input frequency is given and not calculated as it wastes unnecessary
>>> time. It works very well now. I will use a fast opto coupler to drive
>>> the power source and hopefully I have a solution.
>>>
>>> #define MainPeriod 50  // measurement frame duration, milliseconds
>>> #define pulseInput  2   // input pin for pulseIn
>>> #define pulseOutput4
>>>
>>> long previousMillis = 0;
>>> unsigned long duration = 0; // receive pulse width
>>> unsigned long outDuration = 0;
>>> long pulsecount = 0;
>>> long dc = 0;
>>>
>>> float Freq = 0.2e3;
>>> float T = 1 / Freq;
>>> void setup()
>>> {
>>>pinMode(pulseInput, INPUT);
>>>Serial.begin(19200);
>>>pinMode(ledPin, OUTPUT);
>>>analogWriteFrequency(4, 4); //set the pwm frequency = 25usec
>>>analogWriteResolution(10); // use the highest resolution
>>> }
>>>
>>> void loop()
>>> {
>>>unsigned long currentMillis = millis();
>>>if (currentMillis - previousMillis >= MainPeriod)
>>>{
>>> previousMillis = currentMillis;
>>> dc = (duration / 5e-3)/1000;
>>> dc = dc / 100;
>>> outDuration = (dc * 1024)/100;
>>> analogWrite(pulseOutput, outDuration);
>>>
>>> // write current time and F values to the serial port
>>> // not implimented for production but handy to see the frequencies
>>>
>>> //Serial.print(currentMillis);
>>> //Serial.print(" "); // separator!
>>>
>>> /*Serial.print(dc);
>>> Serial.print(" ");
>>> Serial.print(pulsecount);
>>> Serial.print(" ");
>>> Serial.print(duration);
>>> Serial.print(" ");
>>> Serial.println(outDuration);*/
>>>
>>> duration = 0;
>>> pulsecount = 0;
>>>
>>>}
>>>// instead of single measurement per cycle - accumulate and average
>>>duration += pulseIn(pulseInput, HIGH, MainPeriod * 900);
>>>pulsecount++;
>>>
>>> }
>>>
>>>
>>>
 On 25.08.15 14:27, Marius Liebenberg wrote:
> Erik
>   I am getting to old to be a purist any more. I always use the
> platform
>   or chip with the best or most intuitive dev environment.
>   Short piece of code using a Teensy 3.0. I use the Visual Micro
> debugger
>   in Microsoft Visual Studio 2015 all running on the latest Arduino
>   environment.
 . Marius, I've feared I'm too old to learn the newfangled
 Arduino environment, so I'm thrilled to see how you've leveraged it.
 The speed of getting it going is very impressive. I should take a
 closer
 look at the environment - I think I've seen somewhere that it can be
 used with the gnu toolchain.

 Erik

 --
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users
>>> --
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>> --
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
> 

-- 
Sebastian Kuzminsky

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] Is the Linuxcnc Web site ok?

[jrmitchellj .]

I am getting "forbiden" message when I try to connect to it.
It worked fine earlier today.

Ray
On Aug 26, 2015 12:50 AM, "Marius Liebenberg" 
wrote:

> I changed the input spindle frequency to 200Hz and fixed the scaling.
> The input frequency is given and not calculated as it wastes unnecessary
> time. It works very well now. I will use a fast opto coupler to drive
> the power source and hopefully I have a solution.
>
> #define MainPeriod 50  // measurement frame duration, milliseconds
> #define pulseInput  2   // input pin for pulseIn
> #define pulseOutput4
>
> long previousMillis = 0;
> unsigned long duration = 0; // receive pulse width
> unsigned long outDuration = 0;
> long pulsecount = 0;
> long dc = 0;
>
> float Freq = 0.2e3;
> float T = 1 / Freq;
> void setup()
> {
>   pinMode(pulseInput, INPUT);
>   Serial.begin(19200);
>   pinMode(ledPin, OUTPUT);
>   analogWriteFrequency(4, 4); //set the pwm frequency = 25usec
>   analogWriteResolution(10); // use the highest resolution
> }
>
> void loop()
> {
>   unsigned long currentMillis = millis();
>   if (currentMillis - previousMillis >= MainPeriod)
>   {
>previousMillis = currentMillis;
>dc = (duration / 5e-3)/1000;
>dc = dc / 100;
>outDuration = (dc * 1024)/100;
>analogWrite(pulseOutput, outDuration);
>
>// write current time and F values to the serial port
>// not implimented for production but handy to see the frequencies
>
>//Serial.print(currentMillis);
>//Serial.print(" "); // separator!
>
>/*Serial.print(dc);
>Serial.print(" ");
>Serial.print(pulsecount);
>Serial.print(" ");
>Serial.print(duration);
>Serial.print(" ");
>Serial.println(outDuration);*/
>
>duration = 0;
>pulsecount = 0;
>
>   }
>   // instead of single measurement per cycle - accumulate and average
>   duration += pulseIn(pulseInput, HIGH, MainPeriod * 900);
>   pulsecount++;
>
> }
>
>
>
> >On 25.08.15 14:27, Marius Liebenberg wrote:
> >>Erik
> >>  I am getting to old to be a purist any more. I always use the
> >>platform
> >>  or chip with the best or most intuitive dev environment.
> >>  Short piece of code using a Teensy 3.0. I use the Visual Micro
> >>debugger
> >>  in Microsoft Visual Studio 2015 all running on the latest Arduino
> >>  environment.
> >
> >. Marius, I've feared I'm too old to learn the newfangled
> >Arduino environment, so I'm thrilled to see how you've leveraged it.
> >The speed of getting it going is very impressive. I should take a
> >closer
> >look at the environment - I think I've seen somewhere that it can be
> >used with the gnu toolchain.
> >
> >Erik
> >
>
> >--
> >___
> >Emc-users mailing list
> >Emc-users@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Is the Linuxcnc Web site ok?

[Dave Cole]

  I just got this:


  Forbidden

You don't have permission to access / on this server.

Additionally, a 403 Forbidden error was encountered while trying to use 
an ErrorDocument to handle the request.



On 10/13/2015 7:49 PM, jrmitchellj . wrote:
> I am getting "forbiden" message when I try to connect to it.
> It worked fine earlier today.
>
> Ray
> On Aug 26, 2015 12:50 AM, "Marius Liebenberg" 
> wrote:
>
>> I changed the input spindle frequency to 200Hz and fixed the scaling.
>> The input frequency is given and not calculated as it wastes unnecessary
>> time. It works very well now. I will use a fast opto coupler to drive
>> the power source and hopefully I have a solution.
>>
>> #define MainPeriod 50  // measurement frame duration, milliseconds
>> #define pulseInput  2   // input pin for pulseIn
>> #define pulseOutput4
>>
>> long previousMillis = 0;
>> unsigned long duration = 0; // receive pulse width
>> unsigned long outDuration = 0;
>> long pulsecount = 0;
>> long dc = 0;
>>
>> float Freq = 0.2e3;
>> float T = 1 / Freq;
>> void setup()
>> {
>>pinMode(pulseInput, INPUT);
>>Serial.begin(19200);
>>pinMode(ledPin, OUTPUT);
>>analogWriteFrequency(4, 4); //set the pwm frequency = 25usec
>>analogWriteResolution(10); // use the highest resolution
>> }
>>
>> void loop()
>> {
>>unsigned long currentMillis = millis();
>>if (currentMillis - previousMillis >= MainPeriod)
>>{
>> previousMillis = currentMillis;
>> dc = (duration / 5e-3)/1000;
>> dc = dc / 100;
>> outDuration = (dc * 1024)/100;
>> analogWrite(pulseOutput, outDuration);
>>
>> // write current time and F values to the serial port
>> // not implimented for production but handy to see the frequencies
>>
>> //Serial.print(currentMillis);
>> //Serial.print(" "); // separator!
>>
>> /*Serial.print(dc);
>> Serial.print(" ");
>> Serial.print(pulsecount);
>> Serial.print(" ");
>> Serial.print(duration);
>> Serial.print(" ");
>> Serial.println(outDuration);*/
>>
>> duration = 0;
>> pulsecount = 0;
>>
>>}
>>// instead of single measurement per cycle - accumulate and average
>>duration += pulseIn(pulseInput, HIGH, MainPeriod * 900);
>>pulsecount++;
>>
>> }
>>
>>
>>
>>> On 25.08.15 14:27, Marius Liebenberg wrote:
 Erik
   I am getting to old to be a purist any more. I always use the
 platform
   or chip with the best or most intuitive dev environment.
   Short piece of code using a Teensy 3.0. I use the Visual Micro
 debugger
   in Microsoft Visual Studio 2015 all running on the latest Arduino
   environment.
>>> . Marius, I've feared I'm too old to learn the newfangled
>>> Arduino environment, so I'm thrilled to see how you've leveraged it.
>>> The speed of getting it going is very impressive. I should take a
>>> closer
>>> look at the environment - I think I've seen somewhere that it can be
>>> used with the gnu toolchain.
>>>
>>> Erik
>>>
>>> --
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>> --
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Is the Linuxcnc Web site ok?

[jrmitchellj .]

Fyi, I can get to linuxcnc.org/docs

Ray
On Oct 13, 2015 5:35 PM, "Sebastian Kuzminsky"  wrote:

> Something's gone wrong with the website and our hosting provider
> (Dreamcast) has disabled our site.  Our IT specialists have been called
> home from vacation and injected with caffeine for a heroic,
> around-the-clock debugging effort.
>
> Stay tuned for more as this breaking story develops.
>
>
> On 10/13/2015 05:55 PM, Dave Cole wrote:
> >
> >   I just got this:
> >
> >
> >   Forbidden
> >
> > You don't have permission to access / on this server.
> >
> > Additionally, a 403 Forbidden error was encountered while trying to use
> > an ErrorDocument to handle the request.
> >
> >
> >
> > On 10/13/2015 7:49 PM, jrmitchellj . wrote:
> >> I am getting "forbiden" message when I try to connect to it.
> >> It worked fine earlier today.
> >>
> >> Ray
> >> On Aug 26, 2015 12:50 AM, "Marius Liebenberg" 
> >> wrote:
> >>
> >>> I changed the input spindle frequency to 200Hz and fixed the scaling.
> >>> The input frequency is given and not calculated as it wastes
> unnecessary
> >>> time. It works very well now. I will use a fast opto coupler to drive
> >>> the power source and hopefully I have a solution.
> >>>
> >>> #define MainPeriod 50  // measurement frame duration, milliseconds
> >>> #define pulseInput  2   // input pin for pulseIn
> >>> #define pulseOutput4
> >>>
> >>> long previousMillis = 0;
> >>> unsigned long duration = 0; // receive pulse width
> >>> unsigned long outDuration = 0;
> >>> long pulsecount = 0;
> >>> long dc = 0;
> >>>
> >>> float Freq = 0.2e3;
> >>> float T = 1 / Freq;
> >>> void setup()
> >>> {
> >>>pinMode(pulseInput, INPUT);
> >>>Serial.begin(19200);
> >>>pinMode(ledPin, OUTPUT);
> >>>analogWriteFrequency(4, 4); //set the pwm frequency = 25usec
> >>>analogWriteResolution(10); // use the highest resolution
> >>> }
> >>>
> >>> void loop()
> >>> {
> >>>unsigned long currentMillis = millis();
> >>>if (currentMillis - previousMillis >= MainPeriod)
> >>>{
> >>> previousMillis = currentMillis;
> >>> dc = (duration / 5e-3)/1000;
> >>> dc = dc / 100;
> >>> outDuration = (dc * 1024)/100;
> >>> analogWrite(pulseOutput, outDuration);
> >>>
> >>> // write current time and F values to the serial port
> >>> // not implimented for production but handy to see the frequencies
> >>>
> >>> //Serial.print(currentMillis);
> >>> //Serial.print(" "); // separator!
> >>>
> >>> /*Serial.print(dc);
> >>> Serial.print(" ");
> >>> Serial.print(pulsecount);
> >>> Serial.print(" ");
> >>> Serial.print(duration);
> >>> Serial.print(" ");
> >>> Serial.println(outDuration);*/
> >>>
> >>> duration = 0;
> >>> pulsecount = 0;
> >>>
> >>>}
> >>>// instead of single measurement per cycle - accumulate and average
> >>>duration += pulseIn(pulseInput, HIGH, MainPeriod * 900);
> >>>pulsecount++;
> >>>
> >>> }
> >>>
> >>>
> >>>
>  On 25.08.15 14:27, Marius Liebenberg wrote:
> > Erik
> >   I am getting to old to be a purist any more. I always use the
> > platform
> >   or chip with the best or most intuitive dev environment.
> >   Short piece of code using a Teensy 3.0. I use the Visual Micro
> > debugger
> >   in Microsoft Visual Studio 2015 all running on the latest Arduino
> >   environment.
>  . Marius, I've feared I'm too old to learn the newfangled
>  Arduino environment, so I'm thrilled to see how you've leveraged it.
>  The speed of getting it going is very impressive. I should take a
>  closer
>  look at the environment - I think I've seen somewhere that it can be
>  used with the gnu toolchain.
> 
>  Erik
> 
> 
> --
>  ___
>  Emc-users mailing list
>  Emc-users@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/emc-users
> >>>
> --
> >>> ___
> >>> Emc-users mailing list
> >>> Emc-users@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/emc-users
> >>>
> >>
> --
> >> ___
> >> Emc-users mailing list
> >> Emc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> >
> > ---
> > This email has been checked for viruses by Avast antivirus software.
> > https://www.avast.com/antivirus
> >
> --
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 

Re: [Emc-users] Rookie question - what to get to run LinCNC easily/inexpensively

[Karlsson & Wang]

> ...
> Have you guys found anything in particular that might cause latency spikes
> that I'm seeing? I installed 2.7-Wheezy from the pre-built live/install ISO
> and I'm using the onboard video. No extra hardware besides a USB mouse and
> keyboard.
> Also, I'm planning to get a Mesa 5i25 so maybe the latency isn't a problem?
> 
> regards,
> - Claude

I have been thinking about moving the control loop from the PC to the motor 
driver and then latency would be less of a problem. The motor driver I use run 
a control loop at 40kHz while linuxcnc position control loop run at 1kHz but 
with position control in motor driver and linear interpolation I guess 100Hz 
for linuxcnc control loop would be enough.

Nicklas Karlsson

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users