Re: [Emc-users] SJ200 VFD and Modbus

[Kirk Wallace]

On Fri, 2012-02-03 at 16:12 +1100, Frank Tkalcevic wrote:
> So which version do you need?  I've made my own revision 2 driver. 

I have rev. 2, or rather SJ200subscript2. If your component is GPL'd
then I'd appreciate getting a copy, although my problem seems to be with
libmodbus. I'm planning on getting the latest libmodbus and compiling
with that. I've been getting a couple of data type mismatch warnings,
that I have been ignoring because the compile goes through, but I wonder
if I need to address it. On my recent MVX9000 component I had to change
a read function variable to "short int" from "int" because an "int" is
two bytes and the modbus data comes out as single bytes, so two
registers would end up on one HAL pin. Maybe I should cast the
variables, but then I would have to learn how to do that.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Help with a GladeVCP startup error message

[Przemek Klosowski]

On Sun, Jan 22, 2012 at 9:14 PM, Steve Blackmore  wrote:

> Beware - of these gotcha's
>
> No jog in feedhold! -  So don't break an insert or get a swarf ball
> around a tool!!!
>
> Taper thread pitches are measured along the hypotenuse ???
> ...
> Unfortunately any changes to EMC only happen if you can do it yourself
> even when you can prove it's sensible or Industry standard. Committee
> member ego's seem to overrule standards or common sense.
>
> Explains really why it's still a niche application with so few users...
>

Now, this is unfair. I am no EMC guru but I think it's disingenuous to
blame the personalities. Jog apparently is hard and people who can program
don't know how to do it in a way that wouldn't be an embarrassment. As to
tapered threads, I agree with the argument that the hypotenuse pitch allows
threading at any angle, so it's more correct. Both issues were discussed
extensively and good arguments were given.

I would like to bring up the acronym ASAPSIYH: As Soon As Possible, Sooner
If You Help. Or at least refrain from trolling.
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] SJ200 VFD and Modbus

[Frank Tkalcevic]

So which version do you need?  I've made my own revision 2 driver. 

> -Original Message-
> From: Kirk Wallace [mailto:kwall...@wallacecompany.com]
> Sent: Friday, 3 February 2012 2:51 PM
> To: LinuxCNC Users List
> Subject: [Emc-users] SJ200 VFD and Modbus
> 
> I'm trying to get my SJ200 VFD connected with Modbus. In preparation for
> this I ported a MVX9000 which I had on the shelf. It turned out to be a
slam
> dunk, almost.
> http://www.wallacecompany.com/machine_shop/EMC2/mvx9000/
> 
> The SJ200 is a different story. It turns out Hitachi made a rev. 1 and 2
of the
> hardware, and the register addresses are different. I only found the rev.
1
> manuals on-line, but fortunately had a paper manual, that I finally found,
> which indicated what the problem was.
> 
> Plus, there is conflicting information in the application notes about the
> resister addresses being offsets from the register type base address. For
> holding registers, it appears to be 40001. In practice thogh, the Modbus
> query uses only the offset and the query type, read holding register in
this
> case, and the absolute address is handled inside the VFD.
> 
> I am able to modpoll the proper registers now, but I have a problem with
> reading more than two holding registers in my component. It looks like
I'll
> need to get into the bowels of libmodbus, unless someone here has dealt
> with this problem and can provide some advise. Thanks.
> --
> Kirk Wallace
> http://www.wallacecompany.com/machine_shop/
> http://www.wallacecompany.com/E45/index.html
> California, USA
> 
> 
>

--
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] SJ200 VFD and Modbus

[Kirk Wallace]

I'm trying to get my SJ200 VFD connected with Modbus. In preparation for
this I ported a MVX9000 which I had on the shelf. It turned out to be a
slam dunk, almost. 
http://www.wallacecompany.com/machine_shop/EMC2/mvx9000/ 

The SJ200 is a different story. It turns out Hitachi made a rev. 1 and 2
of the hardware, and the register addresses are different. I only found
the rev. 1 manuals on-line, but fortunately had a paper manual, that I
finally found, which indicated what the problem was.

Plus, there is conflicting information in the application notes about
the resister addresses being offsets from the register type base
address. For holding registers, it appears to be 40001. In practice
thogh, the Modbus query uses only the offset and the query type, read
holding register in this case, and the absolute address is handled
inside the VFD.

I am able to modpoll the proper registers now, but I have a problem with
reading more than two holding registers in my component. It looks like
I'll need to get into the bowels of libmodbus, unless someone here has
dealt with this problem and can provide some advise. Thanks.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Possible Retrofit candidate for someone in the heartland

[Kirk Wallace]

On Thu, 2012-02-02 at 21:53 -0500, BRIAN GLACKIN wrote:
> Went for $2555.  People spend more on a card game...  or kids...

I paid around $2000 for my Shizouka, in good shape, with Bandit, tool
changer and some tooling. Hopefully, at this price, the buyer is serious
about restoring it.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] US Digital encoders?

[gene heskett]

On Thursday, February 02, 2012 10:20:56 PM Ed Nisley did opine:

> On Thu, 2012-02-02 at 09:36 -0500, gene heskett wrote:
> > that would require a function generator
> 
> Perhaps gimmicking up a HAL circuit with siggen or freqgen to drive the
> stepper, then compare the encoder input with the motor output? You
> probably don't need a sine wave, just drive the motor back and forth at
> a variable rate: siggen providing a sawtooth wave to freqgen?
> 
> Surely it'd be more complex than that, but triggering on one edge of the
> motor output and looking at the corresponding encoder edges should be
> revealing...

In violent agreement Ed, but what can he use for an exciting signal?

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: 
You have a strong desire for a home and your family interests come first.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] OT: Possible Retrofit candidate for someone in the heartland

[BRIAN GLACKIN]

Went for $2555.  People spend more on a card game...  or kids...

On Wed, Jan 25, 2012 at 2:20 AM, Dave  wrote:

> On 1/25/2012 12:31 AM, Stuart Stevenson wrote:
> >> since I am about 5 miles from the base a second trip would not be a
> >>
> > problem - if I forgot some paperwork
> >
> >
> >
>
> That is extremely convenient.  :-)
>
> The last two base visits I had the GL guy met me at the gate and I
> followed his car back to the pickup location.
>
> No problem.
>
> Dave
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Erik Christiansen]

On 03.02.12 12:49, Erik Christiansen wrote:
> What I did in July does already check for some run-time conflicts which
> I found in the doco, e.g. Turning on radius compensation in an illegal
> plane:

The snippet can pick up the conflict in a simple fall-through gcode
program, but not if the axes are set in a function. Anyone doing that is
on their own.

Erik

-- 
"Unix was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."   - Doug Gwyn


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Erik Christiansen]

On 02.02.12 09:11, John Kasunich wrote:
> On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
> > On 01.02.12 20:32, Kenneth Lerman wrote:
> > > 3 -- A semantic analyzer (whether rule based or coded) will be necessary.
> > 
> > Do you want to prove some property of the gcode program, such as whether
> > it will ever reach the end?
> 
> I've only been loosely following this thread, for example I'm
> not sure of the precise distinction between lexer and parser,

OK, a lexer is basically a text scanner which "tokenises" the input.
It recognises e.g. any Gxxx word, and passes it to the attached parser,
normally with a different token value for each gcode. In contrast, a
numerical constant is passed as e.g. a CONST token, together with its
numeric value in a parser helper variable, e.g. "yyval".

The lexer just lets the parser deal with whole language objects, or
"tokens" as the jargon goes.

> etc., nor have I been keeping track of who wants to do what.
> But I want to put my 2 cents in.

Thanks for bringing the discussion back toward the user perspective.
The more "2 cents" worth, the closer we get to something potentially
useful.

> I think the "property of a g-code program" that a machinist
> is most interested in is "will it run on my machine".  That
> implies far more checking than a simple parser would do.

Yep, I can see that, but as Alan Condit voiced, even a full gcode
grammar (which checks only for legal syntax) is "non-trivial" to
implement. (And we know that this actually means: Just because you
start, doesn't mean you have the stamina to finish.)

Don't we have the simulator for the purpose of checking whether our
latest gcode gem "will it run on my machine"? It will take longer to add
simulation-level checking to a front-end filter, originally only
intended to clean up and formalise input syntax.

> For example, G1 without a feedrate set is an error, and needs
> a meaningful error message.  Doesn't matter to the machinst
> which stage in the parsing/interpreting process generates the
> error.

It is the responsibility of an executable grammar to flag any syntax
error, in a human readable manner. Catching them all would be an
incremental affair, with v0.9 being much better than v0.1.

> Likewise for arcs that fail because the numbers aren't
> precise enough and the endpoint doesn't line up, or an offset
> toolpath that causes gouging.  

While technically that's not grammar, because we've now jumped into
semantics, it is quite feasible to embed enough maths in the grammar
leaf code for this terminal, to pick up the first error this early.

What I did in July does already check for some run-time conflicts which
I found in the doco, e.g. Turning on radius compensation in an illegal
plane:

compensation_modality:  RADIUS ON LEFT  {  if (Plane == YZ)
   error("Operation illegal in the YZ plane.") ;
emit(" G41") ;
}
 |  RADIUS ON RIGHT { if (Plane == YZ)
   error("Operation illegal in the YZ plane.") ;
emit(" G42") ;
}
 |  RADIUS OFF  { emit(" G40") ; }
 ;

Note to self: Factorise that raw first cut of the grammar snippet, so
   the error handling code only appears once.

> If you are going to invent a black box (parser, whatever) that
> takes in some new dialog and spits out g-code, without doing
> all the checks that the interpreter eventually will do, please
> think about the machinist.  When the interpreter eventually
> does spit out an error that says "G3 line 125 endpoint doesn't
> match", will the user be able to correlate that to the error
> in his actual program?  Especially if the new dialect doesn't
> even use the term "G3", or if the translator doesn't preserve
> line numbers (perhaps by discarding comments or blank lines).

Oh. You've changed my mind about chucking out comments. Admittedly, we
couldn't hoik them all out anyway, because of the incomprehensible
weirdness of some comments not actually being comments, but display
statements instead, IIRC.  :-(

Yes, line numbers must correspond, to every feasible extent.
If the user has chosen to use the tool to take "Rapid" as input, in lieu
of "G0", then hopefully he'll have a cheat-sheet on the wall, to cope
with the lower-level machine representation.

All these details are enthusing me for the task of picking up where I
left off, back in July, after a much less enthusiastic on-list
discussion.

Erik

-- 
Programs must be written for people to read, and only incidentally for
machines to execute.- Abelson and Sussman


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, 

Re: [Emc-users] US Digital encoders?

[Ed Nisley]

On Thu, 2012-02-02 at 09:36 -0500, gene heskett wrote:
> that would require a function generator 

Perhaps gimmicking up a HAL circuit with siggen or freqgen to drive the
stepper, then compare the encoder input with the motor output? You
probably don't need a sine wave, just drive the motor back and forth at
a variable rate: siggen providing a sawtooth wave to freqgen?

Surely it'd be more complex than that, but triggering on one edge of the
motor output and looking at the corresponding encoder edges should be
revealing...

-- 
Ed
http://softsolder.com



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] US Digital encoders?

[Viesturs Lācis]

2012/2/2 andy pugh :
> On 2 February 2012 15:09, Viesturs Lācis  wrote:
>
>> Could it be anything else, but the encoder problem?
>
> It could be an unfortunate resonance between the mechanical frequency
> of the machine frame and the servo loop. This might be why increasing
> the servo frequency was helpful.

Increasing servo servo period frequency from 1 kHz to 2kHz helped.
But any further increase up to 5 kHz did not provide any additional improvement.
Even more, with 5kHz (and RTAI errors) I actually have returned at
starting point.

I had some courses, covering resonances, and the conclusion is that
there should have been additional changes in behavior, when further
changes in servo update rate were made. And it should not had gone
back to the initial behavior. But that theory...


2012/2/2 Sven Wesley :
>
> Did you try my suggestion to ground the encoder, as written in my previous
> mail?

Sorry, I forgot. The thing is that I did not find that there was not
an issue with lost encoder pulses anyway...

Viesturs

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Control a hot wire foam cutter using LinuxCNC?

[Peter Georgi]

Thank you Andy, I will follow your instructions .

Regards Peter

-Ursprüngliche Nachricht-
Von: Andy Pugh [mailto:bodge...@gmail.com] 
Gesendet: Mittwoch, 1. Februar 2012 23:27
An: Enhanced Machine Controller (EMC)
Betreff: Re: [Emc-users] Control a hot wire foam
cutter using LinuxCNC?



On 1 Feb 2012, at 19:03, "Peter Georgi"
 wrote:

> I found the file with the
> patch from Lothar and downloaded it. So far so
good. But I do not have 
> any idea how to install it. Is their any
procedure or just copy it 
> into the Axis directory and rename it?

I am in a hotel on my phone, so can't really check
anything, but typically a "patch" is a list of
changes to a number of files and has to be merged
into the source code which is then recompiled. 
It is a bit different for Axis, as that is in
python which is an interpreted language, but I am
not sure how deep the changes go. 
If the patch contains changes to C or C++ files
then you will need to install git, download the
source code, install the build dependencies, merge
the patch and recompile. None of this is
particularly difficult, even if it sounds it. The
wiki.linuxcnc.org page on installing EMC2
describes the process. 

Man patch and/or man git patch might help too. 

It is not impossible to read the patch file and
make the changes manually. 


--

Keep Your Developer Skills Current with
LearnDevNow!
The most comprehensive online learning library for
Microsoft developers is just $99.99! Visual
Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when
you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-u
sers


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Passing file names into a subroutine

[dave]

On Thu, 2 Feb 2012 17:33:10 +0200
andy pugh  wrote:

> On 2 February 2012 17:09, Alan Condit  wrote:
> 
> > Gee, I bet that news would surprise Kernigan and Ritchie. I've been
> > using strings in 'C' since 1977.

So much of K&R C was almost a 1:1 correspondence with PDP-11 machine
instructions. :-)
> 
> No, you have been using arrays of chars, and an external library to do
> even simple things like compare two strings to see if they match.
> 
> I am not saying that C can't process textual data, but it certainly
> has no built in types for strings.

Whereas, Pascal does. OT ... I'm it is rumored that really fast code is
produced by writing in Pascal then using p2c to translate to C before
compiling. 

Dave
> 


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Passing file names into a subroutine

[andy pugh]

On 2 February 2012 17:09, Alan Condit  wrote:

> Gee, I bet that news would surprise Kernigan and Ritchie. I've been using 
> strings in 'C' since 1977.

No, you have been using arrays of chars, and an external library to do
even simple things like compare two strings to see if they match.

I am not saying that C can't process textual data, but it certainly
has no built in types for strings.

-- 
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] rs274ngc bison/flex parser

[Michael Haberler]

Am 02.02.2012 um 03:02 schrieb Kenneth Lerman:

>> READ =>  s(hundred) m 3
>> bad number format (conversion failed) parsing ''
>> s(hundred) m 3
>> 
>> That kind of 'language spec' can stand improvement.. so my parser doubles as 
>> a reverse-engineering tool;)
> I believe that the comment IS being ignored. The objection isn't to the 
> comment; it is to the letter m.

My above example was botched. This really shows what I was referring to:

READ => s(comment)200 
bad number format (conversion failed) parsing ''
s(comment)200

I thinkt this *should* parse as 'S200'

- Michael


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] US Digital encoders?

[Sven Wesley]

2012/2/2 Viesturs Lācis 

> ...
> So my conclusion is - machine is not losing encoder counts, there is
> no significant noise in encoder signal.
>
> Could it be anything else, but the encoder problem?
> ...
>

Did you try my suggestion to ground the encoder, as written in my previous
mail?

/Sven
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Passing file names into a subroutine

[Alan Condit]

> On 2 February 2012 03:51, Kenneth Lerman  wrote:
> 
>> BTW: That's another place where it would be nice to have variables with
>> string values.
> 
andy pugh  wrote:
> Considering that C doesn't really do strings, adding them to G-code
> might be nontrivial.
> 
> -- 
> atp

Gee, I bet that news would surprise Kernigan and Ritchie. I've been using 
strings in 'C' since 1977.

Alan
---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

Email -- acon...@ipns.com
Home-Office (503) 982-0906


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] US Digital encoders?

[andy pugh]

On 2 February 2012 15:09, Viesturs Lācis  wrote:

> Could it be anything else, but the encoder problem?

It could be an unfortunate resonance between the mechanical frequency
of the machine frame and the servo loop. This might be why increasing
the servo frequency was helpful.

Adding some mass to the gantry temporarily, and seeing if that makes
it worse, might be informative, but working from there to a solution
is less easy.

-- 
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] US Digital encoders?

[gene heskett]

On Thursday, February 02, 2012 08:51:35 AM Viesturs Lācis did opine:

> 2012/1/31 Peter C. Wallace :
> >  This can be mitigated by putting a common mode choke (Big
> > 
> > ferrite bead) over the three motor leads (DO NOT include the ground
> > lead)
> 
> 1) I wrapped each of 3 power wires for motor around a separate ferrite
> bead. 2) I connected machine frame to common earth ground.
> 
That isn't the ideal method, although at 50 or 60 hz, not terribly 
important.  We normally use the chokes as common items, where all leads are 
wound on the same toroid form.  The latter doesn't block load surge noises 
because those will generally result in magnetic cancellation.  The general 
idea is to block the longitudinal noise, keeping that soundly choked off in 
the motor itself.  Brush arcing noises etc.

I have not personally noted a problem in my lashup, but I've tried to 
maintain a star grounding and shield connection scheme too.  But when I 
hooked up a probe a few days ago, I did find that I had to ground the 
probes shield to the machine frame, else when the probe circuit was closed 
to ground, halscope was showing quite a bit of noise that seemed to be 
related to the powerline frequency.

> > Please try the encoder sample rate lowering example I provided. This
> > will quickly help to see if there is a noise problem. Noise piked up
> > by the encoder wires either inductively or capacitively tends to be
> > short pulses. By lowering the input bandwidth a lot of this kind of
> > noise can be filtered out.

It also delays things, making stable setups harder to achieve because of 
the lag in the feedback.  although if you've limited it to 3mhz with the 
code below, I can't bring myself to pointing a finger at it. You still have 
far more effective bandwidth at 3mhz than any modification of the servo 
drive, the rotational inertia of the motors armature mass likely limits its 
rate of change to well below 50 kilohertz even in an ironless motor.

Ed:  Is there some method he could use, using halscope, that could 
characterize a mechanical resonance from torsion in the drive and/or this 
questionable encoder & prove there is an instability causing lag someplace.  
The only thing I can think of ATM would need a function generator to supply 
a low amplitude, enough to move the machine 20 thousandths back and forth, 
varying this drive frequency from about 0.1hz up.  If its the lag in the 
encoder, the lag should be both visible in halscope, and varying the 
frequency of the function generator might make it resonate & go crazy at a 
relatively low frequency.  But that would require a function generator 
which I doubt Viesters has access to.

Is there some other tool such as another pwmgen cobbled up out of hal stuff 
in linuxcnc's bag of tricks that could do this?

Just thinking out loud, YMMV.

> 3) Edited INI file, so that firmware load line is this:
> CONFIG="firmware=hm2/5i23/SVSTTP6_6_7I39.BIT num_encoders=3
> num_3pwmgens=3 num_stepgens=2 enable_raw"
> 
> 
> 4) Added to HAL file these lines:
> 
> setp hm2_[HOSTMOT2](BOARD).0.raw.write_address  13312
> # = 0x3400 = encoder Sample Rate Register
> 
> setp hm2_[HOSTMOT2](BOARD).0.raw.write_data 14
> # sample rate is clocklow (48 MHz)/SRR+2
> # so divide by 16 = 3 Mhz
> 
> setp hm2_[HOSTMOT2](BOARD).0.raw.write_strobe   1
> # do write
> 
> 5) In "Show machine config" I additionally ran:
> setp hm2_5i23.0.raw.write_strobe 1
> 
> > Here's one way to check for lost encoder counts:
> > 
> > Mark the shaft and the stator with a pencil/scribe at DRO reading of
> > 0. Move around a lot or until you have the stall problem, turn off
> > motor power and hand crank back to DRO 0 and check pencil mark
> > alignment. This should get you to within a few 10s of counts
> 
> 6) Scratched a mark in pulley and straight line in motor mounting plate.
> Aligned so that mark was on the line.
> Started up Emc.
> In Hal Meter I opened encoder.0.rawcounts pin, which had a value of 0.
> Jogged the joint, motor stalled at least 10 times, each time I stopped
> it with F2, then pressed F2 again, jogged again until it stopped and
> started to oscillate, so I stopped again with F2 and so on.
> After a while I turned off motor power (encoder power remained) and
> aligned the mark and the line (I could not see the screen while doing
> that).
> Rawcounts pin had a value -1
> 
> 7) I tested - jogging bare motor works just fine, which, in case of
> acceleration lag in encoder, is obvious.
> 
> The first 5 points were implemented so that all of them were in
> effect, when last point was conducted.
> 
> The observed impact of first 5 points - NONE.
> 
> So my conclusion is - machine is not losing encoder counts, there is
> no significant noise in encoder signal.
> 
> Could it be anything else, but the encoder problem?
> 
> Viesturs
> 
> 
> -- Keep Your Developer Skills Current with LearnDevNow!
> The most compr

Re: [Emc-users] question on gcode parsing

[John Kasunich]

On Thu, Feb 2, 2012, at 09:11 AM, John Kasunich wrote:
> 
> If you are going to invent a black box (parser, whatever) that
> takes in some new dialog and spits out g-code, without doing

I meant "dialect", not "dialog", sorry

> all the checks that the interpreter eventually will do, please
> think about the machinist.  When the interpreter eventually
> does spit out an error that says "G3 line 125 endpoint doesn't
> match", will the user be able to correlate that to the error
> in his actual program?  Especially if the new dialect doesn't
> even use the term "G3", or if the translator doesn't preserve
> line numbers (perhaps by discarding comments or blank lines).
>
-- 
  John Kasunich
  jmkasun...@fastmail.fm


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[John Kasunich]

On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
> On 01.02.12 20:32, Kenneth Lerman wrote:
> > 3 -- A semantic analyzer (whether rule based or coded) will be necessary.
> 
> Do you want to prove some property of the gcode program, such as whether
> it will ever reach the end?

I've only been loosely following this thread, for example I'm
not sure of the precise distinction between lexer and parser,
etc., nor have I been keeping track of who wants to do what.
But I want to put my 2 cents in.

I think the "property of a g-code program" that a machinist
is most interested in is "will it run on my machine".  That
implies far more checking than a simple parser would do.

For example, G1 without a feedrate set is an error, and needs
a meaningful error message.  Doesn't matter to the machinst
which stage in the parsing/interpreting process generates the
error.  Likewise for arcs that fail because the numbers aren't
precise enough and the endpoint doesn't line up, or an offset
toolpath that causes gouging.  

If you are going to invent a black box (parser, whatever) that
takes in some new dialog and spits out g-code, without doing
all the checks that the interpreter eventually will do, please
think about the machinist.  When the interpreter eventually
does spit out an error that says "G3 line 125 endpoint doesn't
match", will the user be able to correlate that to the error
in his actual program?  Especially if the new dialect doesn't
even use the term "G3", or if the translator doesn't preserve
line numbers (perhaps by discarding comments or blank lines).
-- 
  John Kasunich
  jmkasun...@fastmail.fm


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] US Digital encoders?

[Viesturs Lācis]

2012/1/31 Peter C. Wallace :
>
>  This can be mitigated by putting a common mode choke (Big
> ferrite bead) over the three motor leads (DO NOT include the ground lead)

1) I wrapped each of 3 power wires for motor around a separate ferrite bead.
2) I connected machine frame to common earth ground.

> Please try the encoder sample rate lowering example I provided. This will
> quickly help to see if there is a noise problem. Noise piked up by the
> encoder wires either inductively or capacitively tends to be short pulses.
> By lowering the input bandwidth a lot of this kind of noise can be filtered
> out.

3) Edited INI file, so that firmware load line is this:
CONFIG="firmware=hm2/5i23/SVSTTP6_6_7I39.BIT num_encoders=3
num_3pwmgens=3 num_stepgens=2 enable_raw"


4) Added to HAL file these lines:

setp hm2_[HOSTMOT2](BOARD).0.raw.write_address  13312
# = 0x3400 = encoder Sample Rate Register

setp hm2_[HOSTMOT2](BOARD).0.raw.write_data 14
# sample rate is clocklow (48 MHz)/SRR+2
# so divide by 16 = 3 Mhz

setp hm2_[HOSTMOT2](BOARD).0.raw.write_strobe   1
# do write

5) In "Show machine config" I additionally ran:
setp hm2_5i23.0.raw.write_strobe 1

> Here's one way to check for lost encoder counts:
>
> Mark the shaft and the stator with a pencil/scribe at DRO reading of 0. Move
> around a lot or until you have the stall problem, turn off motor power and
> hand crank back to DRO 0 and check pencil mark alignment. This should get you
> to within a few 10s of counts

6) Scratched a mark in pulley and straight line in motor mounting plate.
Aligned so that mark was on the line.
Started up Emc.
In Hal Meter I opened encoder.0.rawcounts pin, which had a value of 0.
Jogged the joint, motor stalled at least 10 times, each time I stopped
it with F2, then pressed F2 again, jogged again until it stopped and
started to oscillate, so I stopped again with F2 and so on.
After a while I turned off motor power (encoder power remained) and
aligned the mark and the line (I could not see the screen while doing
that).
Rawcounts pin had a value -1

7) I tested - jogging bare motor works just fine, which, in case of
acceleration lag in encoder, is obvious.

The first 5 points were implemented so that all of them were in
effect, when last point was conducted.

The observed impact of first 5 points - NONE.

So my conclusion is - machine is not losing encoder counts, there is
no significant noise in encoder signal.

Could it be anything else, but the encoder problem?

Viesturs

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Fear and Loathing on the Internet

[Mark Wendt]

On 02/01/2012 03:05 PM, Sebastian Kuzminsky wrote:
> On Feb 1, 2012, at 09:13 , Matt Shaver wrote:
>
>
>> What I can offer is to be the defendant of any lawsuits against the
>> project. Any entity, like EMC Corporation, who feels they have a claim
>> against the project can feel free to sue me if they like.
>>  
>
> And if anyone has electronic equipment (such as computers) plugged in to wall 
> outlets (such as power or Ethernet), I volunteer to sit on your roof and act 
> as a lightning rod.
>
>
>
I'll supply the beer and popcorn.

Mark

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] rs274ngc bison/flex parser

[Erik Christiansen]

On 01.02.12 16:45, Michael Haberler wrote:
> 
> 
> Am 01.02.2012 um 13:36 schrieb Erik Christiansen:
> 
> > On 01.02.12 11:48, Michael Haberler wrote:
> Currently I dont see a formal way to describe the interdependencies of
> several words on a block. You can do the optional parameter words in
> the language but you cant recogize the conflicts and multiple uses
> within a block that way. It would be nice to have.

I'm no gcode expert, but I've read some of the constraints in the doco,
and I'd like to try handling some of them, once this thread fizzles.
Admittedly though, it takes some extra effort.

...

> I'd like to see an unambiguous grammar reference. 
> 
> So that parser is a start in that direction. Eventually the real thing
> should actually execute that grammar, there's no point in having an
> executable doing one thing and the LinuxCNC interpreter something
> slightly different. That's not urgent though.

That's good, because it's a long way to there from here. (And even if an
Irishman might say "If I was going there, I wouldn't start from here.",
then we'll just begin with the first step, I think.)

Erik

-- 
Conceptual integrity in turn dictates that the design must proceed from one
mind, or from a very small number of agreeing resonant minds.
   - Frederick Brooks Jr., "The Mythical Man Month"

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Erik Christiansen]

On 01.02.12 08:42, dave wrote:
> On Wed, 1 Feb 2012 19:34:09 +1100
> Erik Christiansen  wrote:
> 
> > On 31.01.12 21:45, dave wrote:
> > 
> > > To my uncluttered mind ... read blank ... 
> > > is this a good way to set the state of a machine at any given line
> > > as a precursor to "restart from line no"?
> > 
> > IIUC¹, running an interpreter through the code from line 1 to a given
> > line, with all external actions suppressed, ought to "set the state
> > of a machine" for that line, if the gcode takes no input, and does no
> > probing. i.e. state is dependent only on the running of the gcode.
> > (But that's just theory, aka a WAG. Experts may differ.)
> > 
> > Erik
> > 
> > ¹ I'm not sure what part of the 129 lines quoted constitute
> > "this". ;-)
> > 
> Erik, 
> The theory seems to work. Years ago I wrote such in C but I put in the
> dropbox and is has gotten lost in my transitions of machines and the
> apparent disappearance of the dropbox. 
> I was just wondering if there was a better way. 

Judging from the several posts warning us that tracking run-time values
of modalities is a problem, I'd say no-one has found a way. (That
doesn't mean ya can't do it with a Quantum computer, IIUC the hype which
surrounds them. ;)

Oh, the pain of losing the blood, sweat, and tears which went into a
good hand-hewn tool. (I have 8 copies of my favourite, and my 300+ pages
of software survival notes. My memory is crumbling 20 years earlier than
Gene's, so I _need_ those notes to remain efficient.)

Erik

-- 
Never worry about theory as long as the machinery does what it's
supposed to do. 
   - Robert A. Heinlein


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] question on gcode parsing

[Erik Christiansen]

On 01.02.12 20:32, Kenneth Lerman wrote:
> On 01/31/2012 11:14 PM, Erik Christiansen wrote:
> > Any "need" to know the run-time state of a modality before run-time is
> > illusory. That which needs to be known at run-time needs to be known at
> > run time, not before. It is worth understanding that the run-time value
> > of a modality is not part of the grammar. I'm not sure what you're
> > basing these imaginary concerns on, but I can't relate them to reality,
> > despite some effort  :-)
> 
> In the past you've implied this,

When dragged off onto the topic of interpreters, I've had to discuss
what happens _at_ run-time. Now let's read the above paragraph again. ;-)

A language grammar specifies permissible input syntax. It knows nothing
about the (changing) run-time values of variables or states (modalities).

An interpreter _uses_ a grammar, not just to translate input into text
output, as a translator or compiler would, but to execute the code.
Now we have jumped into the run-time universe, and need to track state,
just as we track the values of all the variables.

My current understanding is that a modality ought be initialised at the
start of a gcode program, and changes state according to the run-time
path through the gcode, whether that's straight down the page or dizzy
as a fly dodging the corks dangling round the brim of a swaggy's hat.
That's run-time state, not grammar.

> and roughly three or four posts in the future, you bemoan the fact
> that Haberler's trial grammar "is devoid of any explicit gcode
> grammar."  My concerns were based on previous statements that you
> thought this should be done.

Please put those concerns to rest. There is no intrinsic connection
between a grammar and run-time values.

The problem with the absence of gcode grammar from a trial grammar is
that we have moved no nearer to documenting the LinuxCNC dialect,
because the so-called parser was only a tokeniser, blindly passing any
text from G0 to G999.9 inclusive, without recognising any difference
between G76 and G497.6, as you can see here:

Lexer:
gcode   ({digit}{1,3}((\.{digit})?))

([Gg]{opt_ws}{gcode})   {RETURN_TOKEN(token::TGCODE);}

The parser, as shown upthread, does not receive a value with TGCODE, and
there is only this one token for all ten thousand gcodes that it passes
on like a hollow pipe. The "parser" does _not_even_know_ which gcode it
is blindly letting through. Thus, for LinuxCNC gcode, it is only a
tokeniser in effect, at this stage. Any handling of even one LinuxCNC
gcode remains to be added.

As we were warned when it was posted, it's experimental Mk. 0.1.
My comments just try to clarify what it does now.

> While you could put some grammar rules in place, it is my contention
> that no matter how good the grammar, you will need some semantic
> analysis.

There are clearly different needs out there. The two I'm repeatedly
running back to are; documented grammar, definitely executable, and (if
we can get away with it) a more literate optional input form of the same
LinuxCNC dialect we now use. (There will be some grumbling if it's mixed
in with the grammar for the "kosher" current form. I'll have to look at
keeping them visually separate, if possible.)
...

> In short, I'm suggesting that:
> 1 -- An automated lexer would be useful
> 2 -- An automated parser might be useful (if it can give reasonable 
> error messages, etc AND be reasonably modified.) If minor changes 
> require digging through shift/reduce conflicts and trying to resolve 
> them, that might be reason to avoid such technology.

:-)
It might be worth remembering that shift/reduce conflicts arise from an
ambiguous grammar. Their occurrence help us avoid that. Better a grammar
fix, than unpredictable results in the gcode, when swarf and coolant are
flying.

> 3 -- A semantic analyzer (whether rule based or coded) will be necessary.

Do you want to prove some property of the gcode program, such as whether
it will ever reach the end?

Erik

-- 
Don't believe everything you hear, or anything you say.


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Simulator based on Ubuntu 11.10 Oneiric

[Sven Wesley]

2012/2/2 Yishin Li 

> On Thu, Feb 2, 2012 at 4:59 AM, Sven Wesley  wrote:
>
> > Gentlemen (I've asked before, here are no women),
> >
> > Anders Wallin got the simulator running within 11.10, and I made it as
> well
> > by some slight changes to Anders guide.
> > I wrote it all down at the wiki:
> > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Build_A_Simulator_Manually
> > And made a demo case here: http://youtu.be/PFdNbaBq760
> >
> >
> Interesting Video! Which tool are you using for recording the screen
> operations?
>
> Thanks,
>
> Yishin
>


The Desktop Recorder, it's in the repository.

Regards,
Sven
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] CNC Auction

[andy pugh]

http://www2.ppauctions.com/auction.php?id=52

Some useful looking stuff. (complete machines are an the last two pages)

-- 
atp
The idea that there is no such thing as objective truth is, quite simply, wrong.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users