Quoth [email protected].....
>Send Emc-developers mailing list submissions to
> [email protected]
>
>To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>or, via email, send a message with subject or body 'help' to
> [email protected]
>
>You can reach the person managing the list at
> [email protected]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Emc-developers digest..."
>
>
>Today's Topics:
>
> 1. Re: step losing (Dave Caroline)
> 2. Re: step losing (andy pugh)
> 3. Re: step losing (Jullian)
> 4. 2.7pre7 and Huanyang VFD (Russell Brown)
> 5. Re: 2.7pre7 and Huanyang VFD (Sebastian Kuzminsky)
> 6. Re: 2.7pre7 and Huanyang VFD (Russell Brown)
> 7. Re: 2.7pre7 and Huanyang VFD (Sebastian Kuzminsky)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Thu, 20 Aug 2015 07:17:22 +0100
>From: Dave Caroline <[email protected]>
>Subject: Re: [Emc-developers] step losing
>To: EMC developers <[email protected]>
>Message-ID:
> <CALfYgtm=AL1+7qJLnYD=MOhB4e_JXKoeOES3w-j++hFN=cx...@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>I think the fundamental misunderstanding here is the internal counting
>which is far more accurate and does not have the accumulated error
>that was assumed. Any step error seen (+-1) is where this number is
>digitised and the machine moves to the nearest step.
>
>You may think that going to a high microstep will give you this
>accuracy but please do not fall into this common trap, you need the
>resolution mechanically and as mentioned it needs to be far better
>than the accuracy you want to achieve.
>
>http://www.micromo.com/microstepping-myths-and-realities
>
>Dave Caroline
>
>
>
>------------------------------
>
>Message: 2
>Date: Thu, 20 Aug 2015 10:41:59 +0100
>From: andy pugh <[email protected]>
>Subject: Re: [Emc-developers] step losing
>To: EMC developers <[email protected]>
>Message-ID:
> <CAN1+YZVh=OUonTB7MoaQUy=2aa0apl6c+bsjvp771nac-ud...@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>On 20 August 2015 at 02:39, Jullian <[email protected]> wrote:
>> but i still cannot catch the point.
>
>Let me try.
>
>The step generator maintains an internal counter of steps sent. I
>think that this is 64 bits.
>The step generator position is this count divided by the stepgen
>scale, as floating point.
>
>The motion controller does not send moves, it sends positions. (as
>floating point).
>
>The step generator converts a newly-sent position command to a total
>number of steps, compares that to the count of steps already sent, and
>either steps up or down to the new step count.
>
>So, the calculations are all absolute (from wherever the motors are
>when the machine is turned on, but the homing offsets deal with that)
>rather than incremental, so there is no accumulation of error.
>
>--
>atp
>If you can't fix it, you don't own it.
>http://www.ifixit.com/Manifesto
>
>
>
>------------------------------
>
>Message: 3
>Date: Thu, 20 Aug 2015 19:42:28 +0800
>From: Jullian <[email protected]>
>Subject: Re: [Emc-developers] step losing
>To: EMC developers <[email protected]>
>Message-ID:
> <CAF8TPUNbtV_LxFK=a8=bz51pjf_hig8p8oypg3dugt_w6vx...@mail.gmail.com>
>Content-Type: text/plain; charset=UTF-8
>
>i understand what andy said, maybe that's right.
>
>> On 20 August 2015 at 02:39, Jullian <[email protected]> wrote:
>>> but i still cannot catch the point.
>>
>> Let me try.
>>
>> The step generator maintains an internal counter of steps sent. I
>> think that this is 64 bits.
>> The step generator position is this count divided by the stepgen
>> scale, as floating point.
>>
>> The motion controller does not send moves, it sends positions. (as
>> floating point).
>>
>> The step generator converts a newly-sent position command to a total
>> number of steps, compares that to the count of steps already sent, and
>> either steps up or down to the new step count.
>>
>> So, the calculations are all absolute (from wherever the motors are
>> when the machine is turned on, but the homing offsets deal with that)
>> rather than incremental, so there is no accumulation of error.
>>
>> --
>> atp
>> If you can't fix it, you don't own it.
>> http://www.ifixit.com/Manifesto
>>
>>
>------------------------------------------------------------------------------
>> _______________________________________________
>> Emc-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>
>
>------------------------------
>
>Message: 4
>Date: Thu, 20 Aug 2015 20:59:44 +0100 (BST)
>From: [email protected] (Russell Brown)
>Subject: [Emc-developers] 2.7pre7 and Huanyang VFD
>To: [email protected]
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset=US-ASCII
>
>
>Just upgraded from 2.7pre6 to 2.7pre7 and there's a few issues with the
>new hy_vfd stuff (I have been using the hy_vfd from, IIRC, S.Alford with
>2.6 and 2.7 prior to 2.7pre7. I have a HY02D223B FWIW).
>
>First the trivial but annoying or even a show-stopper for anyone not
>happy to read error messages and edit configs:
>
><name>.rev has changed to <name>.reverse
><name>.fwd has changed to <name>.forward
><name>.modbus-ok has changed to <name>.hycomm-ok
>
><name>.motor-pole-number seems to have gone.
><name>.base-freq seems to have gone.
>
>These were all used in the example custompanel.xml examples I got with
>the 'original' hy_hfd from somewhere on that Internet... and 2.7pre7
>obviously breaks that.
>
>Secondly an error in the hy_vfd man page: -V is shown as setting the
>max motor speed; that should be -S.
>
>Thirdly, and most weirdly, the speed of the spindle is not displayed on
>the VFD, and elsewhere, as commanded.
>
>Having tweaked all the above (and set the max motor speed to 24000 when
>I call hy_vfd with -S 24000) doing S1000 M3 makes the VFD display 800
>RPM. S24000 shows 19200 RPM.
>
>However, my cheap'n'nasty tachometer seems to say that the actual
>spindle speed is the commanded one and not the one displayed.
>
>Still running at S1000, motion.spindle-speed-out shows 800RPM,
><name>.Rott shows 800RPM but <name>.spindle-speed-fb shows 1000RPM.
>
>Here's a snapshot of all the hy_vfd pins while the spindle is commanded
>and actually running at 1000RPM.
>
>http://ruffle.me.uk/pics/misc/at1000rpm.png
>
>Any ideas?
>
>
>--
> Regards,
> Russell
> --------------------------------------------------------------------
>| Russell Brown | MAIL: [email protected] PHONE: 01780 471800 |
>| Lady Lodge Systems | WWW Work: http://www.lls.com |
>| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
> --------------------------------------------------------------------
>
>
>
>------------------------------
>
>Message: 5
>Date: Thu, 20 Aug 2015 17:23:53 -0600
>From: Sebastian Kuzminsky <[email protected]>
>Subject: Re: [Emc-developers] 2.7pre7 and Huanyang VFD
>To: EMC developers <[email protected]>
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset=windows-1252; format=flowed
>
>On 8/20/15 1:59 PM, Russell Brown wrote:
>>
>> Just upgraded from 2.7pre6 to 2.7pre7 and there's a few issues with the
>> new hy_vfd stuff (I have been using the hy_vfd from, IIRC, S.Alford with
>> 2.6 and 2.7 prior to 2.7pre7. I have a HY02D223B FWIW).
>
>Ooh! A user! I'm glad I'm not the only one.
>
>
>> First the trivial but annoying or even a show-stopper for anyone not
>> happy to read error messages and edit configs:
>>
>> <name>.rev has changed to <name>.reverse
>> <name>.fwd has changed to <name>.forward
>> <name>.modbus-ok has changed to <name>.hycomm-ok
>>
>> <name>.motor-pole-number seems to have gone.
>> <name>.base-freq seems to have gone.
>>
>> These were all used in the example custompanel.xml examples I got with
>> the 'original' hy_hfd from somewhere on that Internet... and 2.7pre7
>> obviously breaks that.
>
>Yeah, that's sure a hassle for folks who were using the out-of-tree
>hy-vfd driver. Sorry about that!
>
>But i think overall it's an improvement. The .motor-pole-number and
>.base-freq were unused, other than reporting them in HAL. The
>.modbus-ok name was terribly misleading, because the Huanyang VFD does
>emphatically not use the modbus protocol (even though the manual talks
>about modbus). They made up their own communication protocol, and
>called it modbus. Not cool. And finally, i did not like that ".rev"
>was ambiguous and might mean "revolutions" or "reverse", so i renamed it
>to clarify, and renamed ".fwd" to match. This also follows the informal
>convention we have, for example with pins like "motion.spindle-forward"
>and "motion.spindle-reverse".
>
>I should probably have added a mention of this to the release notes,
>i'll try to remember to do so for 2.7.0.
>
>
>> Secondly an error in the hy_vfd man page: -V is shown as setting the
>> max motor speed; that should be -S.
>
>Oops, cut-n-paste error, thanks. Fixed in v2.7.0-pre7-14-g20beefc.
>
>
>> Thirdly, and most weirdly, the speed of the spindle is not displayed on
>> the VFD, and elsewhere, as commanded.
>>
>> Having tweaked all the above (and set the max motor speed to 24000 when
>> I call hy_vfd with -S 24000) doing S1000 M3 makes the VFD display 800
>> RPM. S24000 shows 19200 RPM.
>>
>> However, my cheap'n'nasty tachometer seems to say that the actual
>> spindle speed is the commanded one and not the one displayed.
>>
>> Still running at S1000, motion.spindle-speed-out shows 800RPM,
>> <name>.Rott shows 800RPM but <name>.spindle-speed-fb shows 1000RPM.
>>
>> Here's a snapshot of all the hy_vfd pins while the spindle is commanded
>> and actually running at 1000RPM.
>>
>> http://ruffle.me.uk/pics/misc/at1000rpm.png
>>
>> Any ideas?
>
>Well this one's interesting, i'll have to look into it more. Thanks for
>the bug report. I'll let you know if i have more questions or if i have
>something for you to test out.
>
>
>--
>Sebastian Kuzminsky
>
>
>
>------------------------------
>
>Message: 6
>Date: Fri, 21 Aug 2015 12:15:30 +0100 (BST)
>From: [email protected] (Russell Brown)
>Subject: Re: [Emc-developers] 2.7pre7 and Huanyang VFD
>To: [email protected]
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset=US-ASCII
>
>
>Re my previous about the VFD showing the wrong speed.
>
>After some Googling and playing around, it turned out to be the PD144
>setting in my VFD (it was set to 2400 and should have been 3000).
>
>Looks like with the previous hy_vfd and settings I was running the
>spindle 20% faster than I thought (the VFD display matched the commanded
>speed).
>
>So Mea Culpa (again) and I don't quite understand why with the older
>version a commanded speed didn't result in the spindle spinning at that
>RPM; however I went back to 2.7-pre6, checked with my tacho and that
>seems to have been the case.
>
>(my other comments about the man page and the pins still stand though).
>
>--
> Regards,
> Russell
> --------------------------------------------------------------------
>| Russell Brown | MAIL: [email protected] PHONE: 01780 471800 |
>| Lady Lodge Systems | WWW Work: http://www.lls.com |
>| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
> --------------------------------------------------------------------
>
>
>
>------------------------------
>
>Message: 7
>Date: Fri, 21 Aug 2015 08:11:23 -0600
>From: Sebastian Kuzminsky <[email protected]>
>Subject: Re: [Emc-developers] 2.7pre7 and Huanyang VFD
>To: EMC developers <[email protected]>
>Message-ID: <[email protected]>
>Content-Type: text/plain; charset=windows-1252
>
>On 08/21/2015 05:15 AM, Russell Brown wrote:
>> After some Googling and playing around, it turned out to be the PD144
>> setting in my VFD (it was set to 2400 and should have been 3000).
>
>Hmm, now I'm confused...
>
>You said your spindle motor is rated for 24,000 RPM, right? In that
>case, with the new driver you should supply the motor speed to the
>driver using the "-S 24000" argument that you helped correct.
>
>The PD144 register can't be set above 9,999 RPM (at least on my Huanyang
>VFD). The old hy_vfd driver used to interpret the PD144 number as 1/10
>the motor's max speed, that's probably where your 2,400 value came from.
> I changed it to instead match the description in the (dodgy) Huanyang
>manual, which says it's the motor's actual max speed. Which means if
>the motor's max speed is more than 9,999, you can't put it in that
>register, so you have to supply it on the command line.
>
>I'm wondering now if I messed up, and i should keep the driver's
>interpretation of PD144 as 1/10 of the motors max speed, like the old
>driver did, and not be so persnickety about following the (unreliable)
>manual.
>
>
>> (my other comments about the man page and the pins still stand though).
>
>Fixed here, thanks for the testing & reporting:
>
>http://linuxcnc.org/docs/2.7/html/man/man1/hy_vfd.1.html#OPTIONS
>
>http://linuxcnc.org/docs/2.7/html/getting-started/updating-linuxcnc.html#_huanyang_vfd_driver
>
>
>--
>Sebastian Kuzminsky
>
>
>
>------------------------------
>
>------------------------------------------------------------------------------
>
>
>------------------------------
>
>_______________________________________________
>Emc-developers mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
>End of Emc-developers Digest, Vol 112, Issue 27
>***********************************************
>
--
Regards,
Russell
--------------------------------------------------------------------
| Russell Brown | MAIL: [email protected] PHONE: 01780 471800 |
| Lady Lodge Systems | WWW Work: http://www.lls.com |
| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
--------------------------------------------------------------------
------------------------------------------------------------------------------
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
