Re: [Emc-developers] IGBT Module Dial-a-Yield Project Ideas

[Curtis Dutton]

Gene can you send some links to some of these drives/motors. I'd like to
read more about them. Sounds like interesting tech. Maybe we can steal some
ideas here. Plus if we get a control board set up and running there is no
reason we couldn't adapt it to run other types of power modules.


On Fri, Apr 5, 2024, 12:44 PM gene heskett  wrote:

> On 4/5/24 08:25, Curtis Dutton wrote:
> > yessir thank you. I studied it a fair bit a few years ago. It's part of
> the
> > inspiration for this for sure.
> >
> > I'd like this new board to run out of thr box linuxcnc hal and maybe we
> can
> > port and adopt lots of the STMBL code into this project.
> >
> > My goal is to have this "controller" be a bone stock hal based system
> much
> > like STMBL except not the "stripped" down hal that Rene created. Which
> I'd
> > assume he had to do because of processing and memory power constraintd. I
> > havent yet started playing with my pine star board but it should have
> more
> > than enough power. Hopefully we can get at least a 4khz thread going on
> it.
> > Maybe more!
> >
> > What are modern servo amplifiers running their pid loop at these days?
>
> Stepper/servo's, since two timers cost money, I suspect are running at
> their basic ultrasonic speed of 22khz or better. It simply does not make
> economic sense to do otherwise.
> >
> >
> > On Fri, Apr 5, 2024, 8:13 AM andy pugh  wrote:
> >
> >> On Fri, 5 Apr 2024 at 11:59, Curtis Dutton  wrote:
> >>
> >>> I'm starting a new project to build a motor drive based upon igbt
> >> modules.
> >>> Hoping to build something that has a single type of controller that
> will
> >>> plug and play with various capacity igbt modules for various size
> motors.
> >>
> >> Are you aware of the STMBL project? That would seem like a very good
> >> starting point, as it already plays well with LinuxCNC, and works with
> >> a wide range of feedback types (Hall sensors, resolvers, encoders  and
> >> serial protocols)
> >> In fact you could probably copy the LV board with only minor changes
> >> (to account for component obsolescence) and make a new HV/power board.
> >>
> >> https://github.com/rene-dev/stmbl/blob/master/README.md
> >>
> >> --
> >> atp
> >> "A motorcycle is a bicycle with a pandemonium attachment and is
> >> designed for the especial use of mechanical geniuses, daredevils and
> >> lunatics."
> >> — George Fitch, Atlanta Constitution Newspaper, 1912
> >>
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
>   soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] IGBT Module Dial-a-Yield Project Ideas

[Curtis Dutton]

That would make sense. Just as a quick search I see 4, 8 and possibly even
16Khz pwm frequencies. I'll report on what mac thread frequency this pine
star board can sustain once I get there.

We can find a board with an fpga onboard if its not workable on its own.

On Fri, Apr 5, 2024, 9:30 AM Thaddeus Waldner  wrote:

> As far as I know, current feedback loops update on each PWM cycle.
>
>
> > On Apr 5, 2024, at 7:27 AM, Curtis Dutton  wrote:
> >
> > yessir thank you. I studied it a fair bit a few years ago. It's part of
> the
> > inspiration for this for sure.
> >
> > I'd like this new board to run out of thr box linuxcnc hal and maybe we
> can
> > port and adopt lots of the STMBL code into this project.
> >
> > My goal is to have this "controller" be a bone stock hal based system
> much
> > like STMBL except not the "stripped" down hal that Rene created. Which
> I'd
> > assume he had to do because of processing and memory power constraintd. I
> > havent yet started playing with my pine star board but it should have
> more
> > than enough power. Hopefully we can get at least a 4khz thread going on
> it.
> > Maybe more!
> >
> > What are modern servo amplifiers running their pid loop at these days?
> >
> >
> >> On Fri, Apr 5, 2024, 8:13 AM andy pugh  wrote:
> >>
> >>> On Fri, 5 Apr 2024 at 11:59, Curtis Dutton  wrote:
> >>>
> >>> I'm starting a new project to build a motor drive based upon igbt
> >> modules.
> >>> Hoping to build something that has a single type of controller that
> will
> >>> plug and play with various capacity igbt modules for various size
> motors.
> >>
> >> Are you aware of the STMBL project? That would seem like a very good
> >> starting point, as it already plays well with LinuxCNC, and works with
> >> a wide range of feedback types (Hall sensors, resolvers, encoders  and
> >> serial protocols)
> >> In fact you could probably copy the LV board with only minor changes
> >> (to account for component obsolescence) and make a new HV/power board.
> >>
> >> https://github.com/rene-dev/stmbl/blob/master/README.md
> >>
> >> --
> >> atp
> >> "A motorcycle is a bicycle with a pandemonium attachment and is
> >> designed for the especial use of mechanical geniuses, daredevils and
> >> lunatics."
> >> — George Fitch, Atlanta Constitution Newspaper, 1912
> >>
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] IGBT Module Dial-a-Yield Project Ideas

[Curtis Dutton]

yessir thank you. I studied it a fair bit a few years ago. It's part of the
inspiration for this for sure.

I'd like this new board to run out of thr box linuxcnc hal and maybe we can
port and adopt lots of the STMBL code into this project.

My goal is to have this "controller" be a bone stock hal based system much
like STMBL except not the "stripped" down hal that Rene created. Which I'd
assume he had to do because of processing and memory power constraintd. I
havent yet started playing with my pine star board but it should have more
than enough power. Hopefully we can get at least a 4khz thread going on it.
Maybe more!

What are modern servo amplifiers running their pid loop at these days?


On Fri, Apr 5, 2024, 8:13 AM andy pugh  wrote:

> On Fri, 5 Apr 2024 at 11:59, Curtis Dutton  wrote:
>
> > I'm starting a new project to build a motor drive based upon igbt
> modules.
> > Hoping to build something that has a single type of controller that will
> > plug and play with various capacity igbt modules for various size motors.
>
> Are you aware of the STMBL project? That would seem like a very good
> starting point, as it already plays well with LinuxCNC, and works with
> a wide range of feedback types (Hall sensors, resolvers, encoders  and
> serial protocols)
> In fact you could probably copy the LV board with only minor changes
> (to account for component obsolescence) and make a new HV/power board.
>
> https://github.com/rene-dev/stmbl/blob/master/README.md
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] IGBT Module Dial-a-Yield Project Ideas

[Curtis Dutton]

Hello all,

I'm starting a new project to build a motor drive based upon igbt modules.
Hoping to build something that has a single type of controller that will
plug and play with various capacity igbt modules for various size motors.

This thing shall be able to act as either a vfd or servo drive.

I know this has been discussed before and it's time to get this idea going.
I'm tired of trying to source drives and vfds and having to learn how to
operate, integrate and maintain all these different devices, when they are
all functionally identical. (not to mention thay they are opaque and closed
source)

I'm starting out part of my investigation using a pine64 board. It's
risc-v based soc with 2 ethernet ports, wifi, bluetooth etc... I'm going to
initially interface it as an ethercat "device"

My first step is to get linux cnc running on it and go from there.

Does anyone have experience with anything risc-v related? Tips, advice,
resources pretty much any pointers are welcome to help me get up to speed
faster.

Also I need an initial igbt module "family" to target. Does anyone have any
suggesstions along those lines as well?


Hope all is well.

Thanks,
  Curtis

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

Re: [Emc-developers] hal_port

[Curtis Dutton]

I submitted a pull request #2166 that has Raster components.

It also includes a sim config to demonstrate how these components can be
integrated.


On Mon, Nov 21, 2022 at 4:58 PM Curtis Dutton  wrote:

> I will get a pull request together for this.
>
> On Mon, Nov 21, 2022 at 2:12 PM Rod Webster 
> wrote:
>
>> Andy,
>> The component is indeed in 2.9. But the sample code  mentioned in the
>> hal_port doc you list aren't.
>> See:
>>
>> https://linuxcnc.org/docs/2.9/html/man/man3/hal_port.3hal.html#SAMPLE%20CODE
>> <
>> https://linuxcnc.org/docs/2.9/html/man/man3/hal_port.3hal.html#SAMPLE%20CODE
>> >
>> So the poor user has no clue on how to use it. Specifically these files
>> were promised to be sent in a  separate Pull request which has not
>> eventuated.
>>
>> https://github.com/DuttonIndustrial/linuxcnc/tree/29127782da2da3e26b8d5e9c233cbaa9fea653a4/configs/sim/axis/laser
>>
>> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/laserpower.comp
>>
>> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/raster.comp
>> It would be great to finish the job off.
>>
>> Rod Webster
>> *1300 896 832*
>> +61 435 765 611
>> Vehicle Modifications Network
>> www.vehiclemods.net.au
>>
>>
>> On Tue, 22 Nov 2022 at 00:18, andy pugh  wrote:
>>
>> > On Mon, 21 Nov 2022 at 12:10, Rod Webster 
>> wrote:
>> >
>> > > Could the examples and tests discussed here and in the docs find their
>> > way
>> > > into the 2.9 release?
>> >
>> > I think that they are already in the prerelease:
>> >
>> > https://linuxcnc.org/docs/2.9/html/man/man3/hal_port.3hal.html
>> >
>> >
>> > --
>> > atp
>> > "A motorcycle is a bicycle with a pandemonium attachment and is
>> > designed for the especial use of mechanical geniuses, daredevils and
>> > lunatics."
>> > — George Fitch, Atlanta Constitution Newspaper, 1912
>> >
>> >
>> > ___
>> > Emc-developers mailing list
>> > Emc-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>>
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>

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

Re: [Emc-developers] hal_port

[Curtis Dutton]

I will get a pull request together for this.

On Mon, Nov 21, 2022 at 2:12 PM Rod Webster  wrote:

> Andy,
> The component is indeed in 2.9. But the sample code  mentioned in the
> hal_port doc you list aren't.
> See:
>
> https://linuxcnc.org/docs/2.9/html/man/man3/hal_port.3hal.html#SAMPLE%20CODE
> <
> https://linuxcnc.org/docs/2.9/html/man/man3/hal_port.3hal.html#SAMPLE%20CODE
> >
> So the poor user has no clue on how to use it. Specifically these files
> were promised to be sent in a  separate Pull request which has not
> eventuated.
>
> https://github.com/DuttonIndustrial/linuxcnc/tree/29127782da2da3e26b8d5e9c233cbaa9fea653a4/configs/sim/axis/laser
>
> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/laserpower.comp
>
> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/raster.comp
> It would be great to finish the job off.
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
>
>
> On Tue, 22 Nov 2022 at 00:18, andy pugh  wrote:
>
> > On Mon, 21 Nov 2022 at 12:10, Rod Webster 
> wrote:
> >
> > > Could the examples and tests discussed here and in the docs find their
> > way
> > > into the 2.9 release?
> >
> > I think that they are already in the prerelease:
> >
> > https://linuxcnc.org/docs/2.9/html/man/man3/hal_port.3hal.html
> >
> >
> > --
> > atp
> > "A motorcycle is a bicycle with a pandemonium attachment and is
> > designed for the especial use of mechanical geniuses, daredevils and
> > lunatics."
> > — George Fitch, Atlanta Constitution Newspaper, 1912
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Interfacing to Magnescale scales

[Curtis Dutton]

I have had good luck with a Motrona SI251. It converts sin/cos to
quadrature. It has many settings and works quite well for reading a fanuc
spindle motor encoder. I think Motrona has a few different types of
converters.

https://www.motrona.com/en/products/signal-converters.html


On Tue, Jun 14, 2022, 4:56 AM andy pugh  wrote:

> On Tue, 14 Jun 2022 at 09:36, Hans Unzner  wrote:
>
> > If you have direct access to the resolver it would be worth a thought to
> > use a "resolver to digital converter", e.g. something like this:
> > https://www.analog.com/en/parametricsearch/10890#/
> > Then you can connect the encoder emulation output to LinuxCNC.
>
> Most Resolver converters (including the Mesa 7i49 and the STMBL drive)
> expect to be supplying the excitation signal and read the output
> synchronously to that signal.
> If the drive is already supplying the excitation most of the
> off-the-shelf converters won't work.
>
> Also, the Magnescales have a much finer pitch and are on the actual
> slides, so there is no worry about backlash between the motor and the
> table.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] another build question

[Curtis Dutton]

I'm wanting to play around inside of rtapi a little bit. But it doesn't
actually seem to be built. If I change a file inside of src/rtapi (like add
in an rtapi_pring_msg statement somewhere) MAKE doesn't seem to see that it
changed and does nothing.

After running make, make setuid, and running a test hal module I don't see
the print statement pop up. (Even though it definitely should)

I'm building for USPACE RT kernel run in place, the latest MASTER.


What am I missing?


Thanks again,
   Curtis

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

Re: [Emc-developers] Trying to include asm/tsc.h

[Curtis Dutton]

#include



On Thu, Jun 2, 2022 at 6:37 AM andy pugh  wrote:

> On Thu, 2 Jun 2022 at 11:15, Curtis Dutton  wrote:
>
> > But I
> > did find tsc_khz which is defined within asm/tsc.h.
>
> > Do any Makefile gurus know what might be going on?
>
> How are you #include-ing it?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] Trying to include asm/tsc.h

[Curtis Dutton]

I'm working on a kernel module that uses rtapi_get_clocks. In the docs it
mentions a CPU_khz kernel variable, but I think that may be outdated. But I
did find tsc_khz which is defined within asm/tsc.h.

My module is within the linuxcnc source tree and I'm building in place.
Debian amd64 rt kernel. I can see that the file is in the kernel headers.
But make (and gcc) complains it doesnt exist.

Do any Makefile gurus know what might be going on?


Thanks,
Curt

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

Re: [Emc-developers] suggestions to improve HOMECOMP/HOMEMOD custom homing infrastructure

[Curtis Dutton]

Is there any plan of eventually removing internal homing and only using a
homing component?

I know it is a big ball of mud in there but perhaps separating motion's
homing logic out from the motion module would be less code overall and also
allow custom homing schemes as well.





On Tue, Apr 19, 2022 at 8:50 AM Dewey Garrett  wrote:

>
> > 1. Could the normal component period variable be
> > implemented in a HOMECOMP?  Currently its not supported.
>
> servo_period is included in the homing.h:homing_init() function:
> Ref:
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.h#L43
>
> A user-built homing module that supports custom homing
> functionality for some joints *and* conventional/legacy
> LinuxCNC functions for other joints has required
> replicating many parts of homing.c in the custom module.
>
> i have been working on a new branch that simplifies
> inclusion of code from homing.c to allow unmodified
> and/or augmented use of any of the base homing api
> functions.
>
> The example homecomp.comp has been updated to
> demonstrate methods to select conventional or custom
> api functions for each joint according to hal pin
> settings.
>
> Ref: https://github.com/LinuxCNC/linuxcnc/commits/dgarr/homebase
>
> (lightly tested, runtests passes)
> (The api (homing.h) is not changed)
>
> --
> Dewey Garrett
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] ImportError undefined symbol PyUnicode_FromString

[Curtis Dutton]

I'm building the latest master. (c4039741cdc08d56ba8b05cf518bc5cb8c21d835)


I just did a basic in place build

./autogen.sh
./configure
make
sudo make setuid


Everything builds fine. My machine starts up and runs Axis fine.

However my user component imports linuxcnc module and I get

import linuxcnc
ImportError: /home/curtdutt/dev/linuxcnc/lib/python/linuxcnc.so: undefined
symbol: PyUnicode_FromString

I've searched the forums and email lists and can't seem to find an answer.
The build is using python3

Has anyone seen this error yet?

Thanks,
   Curtis

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

[Emc-developers] Harmonic Drive Actuator Serial Encoder

[Curtis Dutton]

My fadal rebuild/retrofit is approaching completion. It's time to start
doing the harmonic drive encoder homework so I can build up a 4th axis.

I will be building a hostmot2 interface for the harmonic drive serial
encoder.

Does anyone know which protocol it uses? I remember someone mentioning
hiperface but I can't find it in the archives.. Does anyone know?

It is an FHA-32C-100-E250-C. I will be driving it with a mesa 8i20.



Thanks,
   Curtis

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

Re: [Emc-developers] Archiving git repositories without recent activity

[Curtis Dutton]

I'm not at all against long running branches of development. I have two
myself (which I need to finish and pull request!) I propose that these
could be moved to personal github accounts and merged later when ready. In
the end removing these tags from the main repository and putting them into
parallel github accounts helps separate concerns and reduces confusion
about what is going on in linuxcnc.

My clone of linuxcnc has so many branches that I dont know what they are
for. I think in general all if these branches end up functioning as noise
to most people. (not saying that they don't contain useful changes) but in
that case why arent we discussing on the dev list and pulling changes into
master

2 semantic cents is all I have to offer here... :-)

-Curt



On Sun, Aug 1, 2021, 2:21 PM andy pugh  wrote:

> On Sun, 1 Aug 2021 at 19:09, Curtis Dutton  wrote:
>
> > Github makes having these branches in the linuxcnc git uneeded. Arent
> these
> > extraneous branches holdovers from the time that linuxcnc was self
> hosting
> > a git server?
>
> Some contain work-in-progress that has not made it into the main branches.
>
> As an example I was reminded today of a branch I made that has the BBB
> PRU drivers in it. But it was never tested so I didn't feel that it
> should be merged.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Archiving git repositories without recent activity

[Curtis Dutton]

I think a cleanup of the main linuxcnc git branches would be beneficial.

Does the linuxcnc main git even need any branches other than the release
(etc...) branches?

Github makes having these branches in the linuxcnc git uneeded. Arent these
extraneous branches holdovers from the time that linuxcnc was self hosting
a git server?

On Thu, Jul 29, 2021, 9:05 PM Jeff Epler  wrote:

> I think we should consider archiving some git repositories under the
> linuxcnc organization that are unlikely to see further development:
>
> https://github.com/LinuxCNC/stretch-live-build (last activity: 2019)
> https://github.com/LinuxCNC/live-wrapper (last activity: 2018)
> https://github.com/LinuxCNC/wizards (last activity: 2017)
>
> Archiving is a reversible process that disables issues and pull
> requests, and shows a notice that the repository is archived.
>
>
> https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/archiving-a-github-repository/about-archiving-repositories
>
> An example of how an archived repository looks:
>
> https://github.com/LinuxCNC/hostmot2-firmware
>
> I volunteer to do the work, which may consist of a small README update
> before checking a box in the github website.
>
> Jeff
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] hostmot2-firmware

[Curtis Dutton]

I see that hostmot2-firmware has been marked as unmaintained.

I will still be be adding components to hostmot2. Next up is a harmonic
drive serial encoder interface for hostmot2.

I'll be submitting the sigma 5 encoder driver code to linux cnc as soon as
I can, though I have been testing it for the last 6 months or so and it is
working. Just need to finish documentation. (If anyone needs this now let
me know and I'll get you some source code to try out)

Will I just be making pull requests to linuxcnc.hostmot2 firmware anyhow?


Thanks,
  Curtis

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

Re: [Emc-developers] hal_port

[Curtis Dutton]

In tests/pyhal there is a python test that manipulates hal ports. It should
help give you an idea about how to manipulate them.

On Sat, Mar 13, 2021 at 1:18 PM Curtis Dutton  wrote:

> Let me know if you have any questions. I'm still working on getting my
> rastering pull request together.
>
> On Wed, Mar 10, 2021 at 7:43 PM Peter C. Wallace  wrote:
>
>> On Wed, 10 Mar 2021, andy pugh wrote:
>>
>> >> Date: Wed, 10 Mar 2021 23:57:28 +
>> >> From: andy pugh 
>> >> Reply-To: EMC developers 
>> >> To: EMC developers 
>> >> Subject: Re: [Emc-developers] hal_port
>> >>
>> >> On Wed, 10 Mar 2021 at 23:56, andy pugh  wrote:
>> >>
>> >> On Wed, 10 Mar 2021 at 23:55, andy pugh  wrote:
>> >>
>> >>
>> https://github.com/DuttonIndustrial/linuxcnc/tree/29127782da2da3e26b8d5e9c233cbaa9fea653a4/configs/sim/axis/laser
>> >
>> > And
>> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/laserpower.comp
>> >
>> >
>> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/raster.comp
>>
>>
>> Thanks for digging that up!
>>
>>
>>
>> Peter Wallace
>> Mesa Electronics
>>
>> (\__/)
>> (='.'=) This is Bunny. Copy and paste bunny into your
>> (")_(") signature to help him gain world domination.
>>
>>
>>
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>

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

Re: [Emc-developers] hal_port

[Curtis Dutton]

Let me know if you have any questions. I'm still working on getting my
rastering pull request together.

On Wed, Mar 10, 2021 at 7:43 PM Peter C. Wallace  wrote:

> On Wed, 10 Mar 2021, andy pugh wrote:
>
> >> Date: Wed, 10 Mar 2021 23:57:28 +
> >> From: andy pugh 
> >> Reply-To: EMC developers 
> >> To: EMC developers 
> >> Subject: Re: [Emc-developers] hal_port
> >>
> >> On Wed, 10 Mar 2021 at 23:56, andy pugh  wrote:
> >>
> >> On Wed, 10 Mar 2021 at 23:55, andy pugh  wrote:
> >>
> >>
> https://github.com/DuttonIndustrial/linuxcnc/tree/29127782da2da3e26b8d5e9c233cbaa9fea653a4/configs/sim/axis/laser
> >
> > And
> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/laserpower.comp
> >
> >
> https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/raster.comp
>
>
> Thanks for digging that up!
>
>
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] HAL Memory Size

[Curtis Dutton]

I can't remember exactly but I think my laser engraver is set to 10Mb. I
haven't seen any issues.

On Mon, Feb 22, 2021, 9:33 AM Chris Morley 
wrote:

> I think our project active core is getting pretty small...
> This is above my pay grade but I agree with you;
> Given no recommendations against.. let's just try it.
>
> Chris
> 
> From: andy pugh 
> Sent: February 22, 2021 9:38 AM
> To: EMC developers 
> Subject: Re: [Emc-developers] HAL Memory Size
>
> On Sat, 20 Feb 2021 at 15:36, andy pugh  wrote:
>
> > What is the drawback of increasing HAL_SIZE? Currently it is set to 85 *
> 4096.
>
> Anybody?
>
> Currently it 348k. I can't imagine that there is any system out that
> that can't find a whole Megabyte spare for HAL.
>
> So why are we so cautious with the size?
>
> I am tempted to increase to 1MB and see what breaks
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] I wish I had a super size 8i20

[Curtis Dutton]

I'd be happy to show how the conversion goes.

I need to do a writeup on the lathe I just finished too. I have yaskawa
encoder modules written for mesa and hostmot2 drivers for those in
linuxcnc. I'm getting ready to publish them soon.

The machine is being delivered next weekend so I haven't gotten to tear
into it yet. From what I can tell it may have the same bolt pattern as the
900W yaskawa servos that I used on the lathe. If so I'll be using them.
Those yaskawas perform so very well with the 8i20 and 2097152 count
encoders.

On Sat, Feb 27, 2021 at 12:27 PM Feral Engineer 
wrote:

> Curt,
>
> Can you please document your progress with the Fadal? There's one at my old
> school I want to dig into eventually with some of the students. It's also a
> VMC 15.
>
> Thanks!
>
> Phil
>
>
> On Sat, Feb 27, 2021, 8:09 AM Curtis Dutton  wrote:
>
> > I've recently purchased a Fadal VMC 15 and I'll be retrofitting it and
> > replacing servos and electronics. The last machine I retrofitted was an
> old
> > miyano gang lathe and I'm driving the spindle and servos with 8i20's. I
> > just love them they are great.
> >
> > Is there any plan for a larger capacity 8i20? I wish I didnt have to buy
> > vfd's for large spindles and could use a super size 8i20. say up to 10hp
> or
> > so.
> >
> > Has this ever been discussed before?
> >
> > -Curt
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] I wish I had a super size 8i20

[Curtis Dutton]

I've recently purchased a Fadal VMC 15 and I'll be retrofitting it and
replacing servos and electronics. The last machine I retrofitted was an old
miyano gang lathe and I'm driving the spindle and servos with 8i20's. I
just love them they are great.

Is there any plan for a larger capacity 8i20? I wish I didnt have to buy
vfd's for large spindles and could use a super size 8i20. say up to 10hp or
so.

Has this ever been discussed before?

-Curt

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

Re: [Emc-developers] reallytrivialkins

[Curtis Dutton]

Yes!

Another reason for this move would be to increase basic consistency within
the project.

I think it would be reasonable for a user of linuxcnc to expect that all
customizations that come "in the box" be buildable with halcompiler. Maybe
that isn't exactly possible right now but moving things in that direction
would be noble.

-Curt

On Sun, Oct 11, 2020 at 9:17 AM andy pugh  wrote:

> I wonder if it is worth adding a minimal kins to the project,
> basically the old hard-coded trivkins with a 1:1 mapping between the
> joints and axes.
> The intention would be that it could be pointed at when answering
> questions about custom kinematics as an example of a skeleton for a
> one-off kinematics file.
>
> Partly this is because the current trivkins does not compile with
> halcompile whereas the old trivialtrivkins does.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] master: configure: Missing Python.h but it exists.

[Curtis Dutton]

I am trying to configure master with Python3. On Ubuntu 20.04

> ./configure --with-python=/usr/bin/python3.8


I get
checking for /usr/include/python3.8/Python.h... no

> ls /usr/include/python3.8/Python.h
outputs
/usr/include/python3.8/Python.h





If I edit configure and change

as_ac_Header=`$as_echo "ac_cv_header_$INCLUDEPY/Python.h" | $as_tr_sh`
ac_fn_c_check_header_mongrel "$LINENO" "$INCLUDEPY/Python.h"
"$as_ac_Header" "$ac_includes_default"
if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :

else
  as_fn_error $? "Required header Python.h missing.  Install it, or specify
--disable-python to skip the parts of LinuxCNC that depend on Python"
"$LINENO" 5
fi

to

as_ac_Header=`$as_echo "ac_cv_header_$INCLUDEPY/Python.h" | $as_tr_sh`
ac_fn_c_check_header_mongrel "$LINENO" "$INCLUDEPY/Python.h"
"$as_ac_Header" "$ac_includes_default"
#if eval test \"x\$"$as_ac_Header"\" = x"yes"; then :

#else
#  as_fn_error $? "Required header Python.h missing.  Install it, or
specify --disable-python to skip the parts of LinuxCNC that depend on
Python" "$LINENO" 5
#fi

configure completes, everything builds and runtests passes.


I'm not sure why it doesn't see Python.h

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

Re: [Emc-developers] 2.8 Situation

[Curtis Dutton]

I'm not familiar exactly with the release process as I'm a RIP guy on all
of my machines and run master.

One of the open source projects I work with (racket-lang) uses a monthly
release schedule with minor releases and then a major release once per
year. They are academics and have funding so doing a monthly release sounds
too hard. However would something along those lines be appropriate? Perhaps
quartly or bi-annual releases?

Is generating a release highly difficult? If so we should work on making
that easier and ideally automatic.

Master functionality vs 2.7 or 2.6 is a very large difference and no matter
when the next release occurs, it is going to be painful for most users to
upgrade. This next release will almost be more of a 3.0 than anything. The
sooner that bandaid gets pulled off the better.

Users need to be accustomed to frequent releases and frequent upgrades if
not just to get them used to doing it.

Now we definitely want RTAI in there, many users need it and linuxcnc needs
as many users as it can get.

Is it possible to get RTAI on a point release after the fact (unless the
bug gets fixed sooner?) Why does the release need to be all or nothing? Can
we do a special RTAI release later as soon as the bug gets fixed just
because it is a special case?



On Thu, Jun 11, 2020 at 12:58 AM Phill Carter 
wrote:

>
>
> > On 11 Jun 2020, at 12:54 pm, Rod Webster  wrote:
> >
> >> On Thu, 11 Jun 2020 at 12:33, Reinhard 
> wrote:
> >>
> >> If other users have similar experiences, then a lot of precious
> developer
> >> time
> >> has been wasted on releases, that don't have much importance.
> >> I believe, that developer time spent on pushing things ahead makes more
> >>  sense,
> >> than spending it on releases.
> >
> > I think that sums it up nicely.
> > Look to the future I say!
>
>
> But I thought you were pushing for a release Rod. ;-)
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Sigma5ABS Implementation - Commutation

[Curtis Dutton]

Ok good. Both an angle pin and passing the hall signals through should be
sufficient to commutate on pico and mesa drives.



On Mon, May 11, 2020 at 3:17 PM Jon Elson  wrote:

> On 05/10/2020 10:20 PM, Curtis Dutton wrote:
> > These do have hall
> > signals to allow initial commutation.
> Ah, that solves the commutation issue.
> > If you had to drive fanuc encoder/servos from a bldc component how would
> > you (roughly speaking) configure them?
> >
> Well, I don't.  I make brushless servo amps that take the
> "Hall" signals to control commutation.
> So, they are simple six-step drives, not sinusoidal.  But,
> that seems to work pretty well.
> There IS a slight discontinuity at the commutation changes,
> but it is really pretty small.
>
> So, for the Fanuc encoders, I make converters that provide
> simulated Hall signals from the
> information available.
>
> Jon
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Sigma5ABS Implementation - Commutation

[Curtis Dutton]

I was worried about a phase-angle needing to be added in. I did read
somewhere that the 8i20 adds this automatically but I wasn't sure. Sounds
like that it does.

I will try direct commutation to the 8i20 and report back.

On Mon, May 11, 2020 at 4:43 AM andy pugh  wrote:

> On Mon, 11 May 2020 at 01:18, Curtis Dutton  wrote:
>
> > Would be possible to use the encoder to output a rotor-angle directly to
> be
> > used with an 8i20 or other type drive thus removing the need for the bldc
> > component when using the yaskawa motor.
>
> That can work, and one of the motors on my lathe is commutated exactly
> that way.
>
> I am using Resolvers.
>
> If the resolver pole count matches the motor pole count and the
> resolver is aligned to the motor, then this works:
>
> net z-angle hm2_5i24.0.resolver.01.angle hm2_8i20.0003.angle
>
> (You will note that I am using the option to address smart-serial
> devices by their serial number, and that I have one of the very first
> 8i20s)
>
> For the X axis, where nether condition is true, I use bldc to adjust
> for pole count differences and offset.
>
> net x-counts hm2_5i24.0.resolver.00.rawcounts => bldc.0.rawcounts
> setp bldc.0.scale -16777216
> setp bldc.0.poles 8
> setp bldc.0.encoder-offset 170
> net x-angle bldc.0.rotor-angle hm2_8i20.008d.angle
>
>
>
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] Sigma5ABS Implementation - Commutation

[Curtis Dutton]

It does sound similar. Yaskawa does have a type of absolute encoder with a
battery backup. Based on the datasheet their absolute encoders have
connector pins for a battery but these ones do not. These do have hall
signals to allow initial commutation. I assume that the yaskawa drives
commutate on the hall signals until the reference point is crossed and then
adjust for normal operation.

If you had to drive fanuc encoder/servos from a bldc component how would
you (roughly speaking) configure them?

-Curt

On Sun, May 10, 2020, 10:50 PM Jon Elson  wrote:

> On 05/10/2020 07:20 PM, Curtis Dutton wrote:
> > I have been able to get the yaskawa sigma5 motors turning with the bldc
> > component in qh mode.
> >
> > The encoders are a sort of hybrid incremental/absolute encoder. Once they
> > pass the index point a flag and an offset are returned in the encoder
> data
> > that allows the exact rotor angle position to be computed.
> >
> > I'm trying to find the best path forward for facilitating commutation.
> Any
> > guidance would be appreciated.
> >
> Fanuc has two types of serial encoders.  ABS and INC, for
> absolute and incremental.
> The incremental type only provide correct shaft angle when
> battery backup is provided.
> If the battery is disconnected or drained, then you have to
> manually crank the motor over
> one full turn so the encoder can see the index position.
> Then, the controller can determine
> commutation from the encoder data.
>
> The absolute type have an additional low-res track that
> provides a 1024 count per quadrant
> data that is aligned to the motor poles, so a drive could
> immediately get commutation data
> when encoder power is on.  Although Fanuc provides a backup
> battery for these encoders,
> it seems it is not totally necessary.
>
> Perhaps the Yaskawa also have provision for battery backup?
> The flag changing when index is sensed
> sounds just like what the Fanuc encoders do.
>
> Jon
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] Sigma5ABS Implementation - Commutation

[Curtis Dutton]

I have been able to get the yaskawa sigma5 motors turning with the bldc
component in qh mode.

The encoders are a sort of hybrid incremental/absolute encoder. Once they
pass the index point a flag and an offset are returned in the encoder data
that allows the exact rotor angle position to be computed.

I'm trying to find the best path forward for facilitating commutation. Any
guidance would be appreciated.


Scenario A

BLDC needs a way to set the exact rotor angle in the bldc component once
the reference point is crossed. I think this may be a slightly different
scenario than bldc currently handles. (Not sure) I imagine hal wiring like
so would be appropriate. Perhaps an "r" mode that allows self referencing
encoders.

bldc config would be "qhr"

net sigma5abs.00.referenced bldc.0.referenced
net sigma5abs.00.ref-offset bldc.0.ref-offset

The motor would be commutated via halls and once the reference point is
crossed the referenced pin goes True and the bldc uses the ref-offset value
to adjust its internal rotor angle value to match.



Scenario B

Have the sigma5 encoder module output a "commutation" count which would
behave like rawcounts, but would "jump" ahead or behind by the reference
offset when the encoder becomes referenced. I don't think that it would be
so large of a jump that would be even noticeable as the bldc component
would have already determined a fairly close alignment via that hall
sensors and the encoder rawcounts.


Scenario C

Would be possible to use the encoder to output a rotor-angle directly to be
used with an 8i20 or other type drive thus removing the need for the bldc
component when using the yaskawa motor. That would simplify configuration
for users. Would that be possible or recommended?


Any other ideas welcome.

Thanks,
   Curt

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

Re: [Emc-developers] Mesa Sigma5ABS module

[Curtis Dutton]

So I have made significant progress on the sigma5abs encoder front. I have
designed a manchester transiever in vhdl and integrated it into hostmot2
firmware as well as linuxcnc. I am close to having a fully functioning
driver. However there are a few mysteries remaining. This is the first
absolute encoder that I have had my hands on so I'm hoping others will know
more.


The encoders are 24 bit with 21 bits per turn so they track 8 turns worth
of counts. Part of the protocol has a 3 bit value that is a sort of turn
counter. It seems to only change if a complete turn is made. For example if
you rotate the encoder until the turn count changes, then reverse, the turn
value will not change until at least an entire rotation occurs. So
depending on the direction and partial reversing, each turn counter value
can occur at 3 different transition points.

This chart shows a mapping between the 24 bit count and possible "turn"
values.



2097152   7 0 1
4194304  0 1 2
6291456  1 2 3
8388608  2 3 4
10485760   3 4 5
12582912  4 5 6
14680064  5 6 7
16777216 (0)6 7 0



What is the technical term for this style of counter? I can see how it
could be used to determine the rollover point of the counter. What possible
ways should this be used?

Thanks,
   Curt

On Mon, Mar 30, 2020, 5:13 PM Curtis Dutton  wrote:

> Ok thanks. Once I get things working and know the register layout of the
> finished module I will get some advice as to a final proper address
> location.
>
> On Mon, Mar 30, 2020 at 5:01 PM Peter C. Wallace  wrote:
>
>> On Mon, 30 Mar 2020, Curtis Dutton wrote:
>>
>> > Date: Mon, 30 Mar 2020 16:33:13 -0400
>> > From: Curtis Dutton 
>> > Reply-To: EMC developers 
>> > To: EMC developers 
>> > Subject: [Emc-developers] Mesa Sigma5ABS module
>> >
>> > Hi all,
>> >
>> > I'm working out the design for the Yaskawa Sigma V absolute encoders.
>> >
>> > Within hostmot2-firmware,
>> >
>> > I've been studying the code and I'm not sure of the exact interface
>> between
>> > the mesa pci cards and linuxcnc.
>> >
>> > It seems that the pci card is mapping registers into memory and that
>> each
>> > module is reserving a register address so that the hostmot2 driver knows
>> > where to look for them to control them.
>> >
>> >
>> > In IDROMConst.vhd, I'm looking for register address space to use. But
>> I'm
>> > getting the feeling that it is all used up. Perhaps that is the reason
>> that
>> > pkuart chose to use the same address's as the uart module.
>> >
>> > The DPLLFreqLowAddr comments "note overlaps translate RAM" and "will
>> fix in
>> > the greate re-alignment"
>> >
>> > Does anyone know what the great re-alignment will be?
>> >
>> > Can anyone shed some light on the addressing scheme used with the mesa
>> > cards. Any other overview of how it works would be useful too.
>>
>> At one time there was only 32K of useable address space because the EPP
>> interfaced cards used the MSB of the address as an address autoinc flag.
>> Since
>> EPP interfaced cards are basically legacy devices at this point, newer
>> hm2
>> modules use addresses > 0x7FFF and currently B000,C000,D000,E000,F000 are
>> all
>> free.
>>
>> At some point, complile time allocation of module addresses might make
>> sense,
>> but that's a fairly large change so I think I'll wait until I run out of
>> address
>> space until I do that.
>>
>> Note, there's no harm in overlap as long as you dont expect to use the
>> overlapping modules in the same configuration
>>
>>
>> >
>> >
>> > Thanks,
>> >   Curt
>> >
>> > ___
>> > Emc-developers mailing list
>> > Emc-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>> >
>>
>> Peter Wallace
>> Mesa Electronics
>>
>>
>>
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>

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

Re: [Emc-developers] Mesa Sigma5ABS module

[Curtis Dutton]

Ok thanks. Once I get things working and know the register layout of the
finished module I will get some advice as to a final proper address
location.

On Mon, Mar 30, 2020 at 5:01 PM Peter C. Wallace  wrote:

> On Mon, 30 Mar 2020, Curtis Dutton wrote:
>
> > Date: Mon, 30 Mar 2020 16:33:13 -0400
> > From: Curtis Dutton 
> > Reply-To: EMC developers 
> > To: EMC developers 
> > Subject: [Emc-developers] Mesa Sigma5ABS module
> >
> > Hi all,
> >
> > I'm working out the design for the Yaskawa Sigma V absolute encoders.
> >
> > Within hostmot2-firmware,
> >
> > I've been studying the code and I'm not sure of the exact interface
> between
> > the mesa pci cards and linuxcnc.
> >
> > It seems that the pci card is mapping registers into memory and that each
> > module is reserving a register address so that the hostmot2 driver knows
> > where to look for them to control them.
> >
> >
> > In IDROMConst.vhd, I'm looking for register address space to use. But I'm
> > getting the feeling that it is all used up. Perhaps that is the reason
> that
> > pkuart chose to use the same address's as the uart module.
> >
> > The DPLLFreqLowAddr comments "note overlaps translate RAM" and "will fix
> in
> > the greate re-alignment"
> >
> > Does anyone know what the great re-alignment will be?
> >
> > Can anyone shed some light on the addressing scheme used with the mesa
> > cards. Any other overview of how it works would be useful too.
>
> At one time there was only 32K of useable address space because the EPP
> interfaced cards used the MSB of the address as an address autoinc flag.
> Since
> EPP interfaced cards are basically legacy devices at this point, newer hm2
> modules use addresses > 0x7FFF and currently B000,C000,D000,E000,F000 are
> all
> free.
>
> At some point, complile time allocation of module addresses might make
> sense,
> but that's a fairly large change so I think I'll wait until I run out of
> address
> space until I do that.
>
> Note, there's no harm in overlap as long as you dont expect to use the
> overlapping modules in the same configuration
>
>
> >
> >
> > Thanks,
> >   Curt
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> Peter Wallace
> Mesa Electronics
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] Mesa Sigma5ABS module

[Curtis Dutton]

Hi all,

I'm working out the design for the Yaskawa Sigma V absolute encoders.

Within hostmot2-firmware,

I've been studying the code and I'm not sure of the exact interface between
the mesa pci cards and linuxcnc.

It seems that the pci card is mapping registers into memory and that each
module is reserving a register address so that the hostmot2 driver knows
where to look for them to control them.


In IDROMConst.vhd, I'm looking for register address space to use. But I'm
getting the feeling that it is all used up. Perhaps that is the reason that
pkuart chose to use the same address's as the uart module.

The DPLLFreqLowAddr comments "note overlaps translate RAM" and "will fix in
the greate re-alignment"

 Does anyone know what the great re-alignment will be?

Can anyone shed some light on the addressing scheme used with the mesa
cards. Any other overview of how it works would be useful too.


Thanks,
   Curt

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

Re: [Emc-developers] pktuart -> rs-485

[Curtis Dutton]

I will write a vhdl module then.

While reading your previous explanation I only noticed rs485 and figured
the rest would be decoding bits in software. My mistake. Pointers to
relevant background would have been useful. I will look into that myself.

Thanks for already figuring this all out. It will be extremely helpful, and
I hope that enabling a path to using yaskawa servos with linuxcnc will help
the cause.


-Curt

On Thu, Mar 26, 2020 at 7:30 AM Rene Hopf via Emc-developers <
emc-developers@lists.sourceforge.net> wrote:

>
>
> > On 25. Mar 2020, at 22:10, Peter C. Wallace  wrote:
> >
> > On Wed, 25 Mar 2020, Curtis Dutton wrote:
> >
> >> Date: Wed, 25 Mar 2020 14:02:39 -0400
> >> From: Curtis Dutton 
> >> Reply-To: EMC developers 
> >> To: EMC developers 
> >> Subject: Re: [Emc-developers] pktuart -> rs-485
> >> Apologies. It is a 7i74 not a 7i84.
> >
> > BTW a simple way to bisect the testing process is to simply loop back
> the FPGA TX line to the FPGA RX line, to eliminate any issues with TXEN,
> polarities, RS-485 driver hookup etc etc
>
> I explained it already, yaskawa is not a uart, its hdlc over Manchester
> over rs485.
> It cannot work with the pkguart or ssi driver.
> To get it to work with a mesa card requires a new vhdl module. It requires
> clock recovery, so you can’t even just pick bits at times.
> This is my implementation in the Stmbl:
> https://github.com/rene-dev/stmbl/blob/master/src/comps/yaskawa.c#L85 <
> https://github.com/rene-dev/stmbl/blob/master/src/comps/yaskawa.c#L85>
> Its decoded with clock recovery by using a timer chained to a dma channel,
> which ends up with a run length encoding in memory.
> The request is also generated with the dma.
> I can make a pcb that converts all the fb systems the Stmbl supports to
> sserial.
>
> >
> >
> > Peter Wallace
> > Mesa Electronics
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] pktuart -> rs-485

[Curtis Dutton]

Apologies. It is a 7i74 not a 7i84.

On Wed, Mar 25, 2020 at 1:47 PM Peter C. Wallace  wrote:

> On Wed, 25 Mar 2020, Curtis Dutton wrote:
>
> > Date: Wed, 25 Mar 2020 12:10:22 -0400
> > From: Curtis Dutton 
> > Reply-To: EMC developers 
> > To: EMC developers 
> > Subject: [Emc-developers] pktuart -> rs-485
> >
> > My current project is connecting a pktuart -> 6i25 -> 7i84 ->yaskwa
> rs-485
> > encoder.
>
> Did you mean 7I85?
>
> >
> > I was able to compile custom hostmot2 firmware with 4 pktuart and 4
> sserial
> > components.
> >
>
> > I have a provisional hal component that is able to send data through 2
> > pktuart modules that wired together via the 7i84 and send bits back and
> > forth at 2 Mbps which is the frequency that yaskawa encoders function at.
> >
> > The encoders use a 2 wire bi-directional rs-485 protocol so I purchased
> > some  mesa 485x1 Rs-485/RS-422 adaptors.
>
> >
> > I can't seem to get them to work.
>
> Are the RS-485 enables connected to PktUART TXEN pins and do they have the
> correct polarity? (Active low)
>
>
> Note that there is a fairly recent fix in the TXEN delay function of the
> PKtUART
> so it should probably be set to 0 for testing
>
> >
> > My testing plan is to get pktuart 0 to communicate with pktuart 1 with 2
> of
> > the RS-485 adapters in between them. This will give me confidence that
> > everything is working properly and can then move on to communicating with
> > the yaskawa encoders.
> >
> > I'm not sure exactly how to wire the adapters and I haven't gotten lucky
> > yet with my attempts.
> >
> > Does anyone have a diagram or information on how to use these adaptors?
> >
> > Do I even have the correct approach here?
> >
> >
> > Thanks,
> >   Curtis
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] pktuart -> rs-485

[Curtis Dutton]

My current project is connecting a pktuart -> 6i25 -> 7i84 ->yaskwa rs-485
encoder.

I was able to compile custom hostmot2 firmware with 4 pktuart and 4 sserial
components.

I have a provisional hal component that is able to send data through 2
pktuart modules that wired together via the 7i84 and send bits back and
forth at 2 Mbps which is the frequency that yaskawa encoders function at.

The encoders use a 2 wire bi-directional rs-485 protocol so I purchased
some  mesa 485x1 Rs-485/RS-422 adaptors.

I can't seem to get them to work.

My testing plan is to get pktuart 0 to communicate with pktuart 1 with 2 of
the RS-485 adapters in between them. This will give me confidence that
everything is working properly and can then move on to communicating with
the yaskawa encoders.

I'm not sure exactly how to wire the adapters and I haven't gotten lucky
yet with my attempts.

Does anyone have a diagram or information on how to use these adaptors?

Do I even have the correct approach here?


Thanks,
   Curtis

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

Re: [Emc-developers] Question for halmodule

[Curtis Dutton]

It should be ok. I will investigate further.

-Curt

On Mon, Jan 13, 2020, 12:48 PM Johannes Fassotte <
johan...@automationassist.com> wrote:

> I have noticed that when compiling halmodule.cc in 2.9 pre 0 that it
> complains that HAL_PORT is not being handled in the switch statements on
> lines 314,  322, 1001, 1023, 1038. Is this something that needs to added
> or can can it just be ignored.?
>
>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] hal_port with documentation

[Curtis Dutton]

Ok I have created a pull request for hal_port pin type to master.

This request only includes hal_port related things. The laser and raster
components will be a different pull request that I will make after this one
gets in.


Thanks all,
   Curtis

On Tue, Aug 6, 2019 at 12:03 PM Curtis Dutton  wrote:

> I can fix the indenting on hal_lib.c
>
> I'm not opposed to separate changes however I did use the pyhal.py to
> create tests for testing hal_port code. pyhal.py is not actually required
> for hal_port to function. (Assuming hal_port functions properly)
>
> The halcompile.g doesn't strictly become a requirement until someone wants
> to generate a .comp using hal_ports.
>
>
> I can't say if pyhal.py should replace halmodule.cc.  My first approach
> was to try to modify halmodule.cc but it was quite difficult to wrap my
> head around which is why I wrote pyhal.py. pyhal.py could potentially
> replace halmocdule.cc but I don't know exactly how that would effect
> existing components. Is there a performance penalty? Can everything that
> halmodule.cc do be done with pyhal.py? I don't know yet.
>
> The remapping of M codes are part of a sample config only. It is an
> example to show how I integrated the raster programmer component with the
> raster realtime component. There are I'm sure many other ways to do this.
>
>
> Right now the raster component is a software only version. My actual laser
> machine has mesa hardware so I ultimately want to use datapainter instead
> of the raster component. I'm sure that the ultimate driver for datapainter
> will work in much the same fashion and share some code with the software
> raster implementation.
>
>
>
> It may be easier to understand if we did this as 2 separate commits.
>
> hal changes
> halcompile.g
> hal_port tests
> pyhal.py
>
>
> then
>
> laserpower.comp
> raster.comp
> rasterprogrammer.py
> raster tests
> as well as the sample config
>
>
>
>
>
>
> On Tue, Aug 6, 2019 at 8:35 AM andy pugh  wrote:
>
>> My opinion only: (I am not sure who has the final say on what goes in to
>> Master)
>>
>> On Mon, 5 Aug 2019 at 15:38, Curtis Dutton  wrote:
>>
>> A HAL_PORT pin allows for a writer component to send many bytes in one
>> > operation to a reader component in real time. The PORT pins behave just
>> > like any other pin in HAL and can be linked, unlinked etc...
>> >
>> > In addition to the modifications to make hal ports some other
>> modifications
>> > and new parts were required.
>> >
>> > halcompile.g - added port type. Also added (pin,param,variable)_ptr
>> macros
>> > to allow access to the actual pointer to those values.
>>
>>
>> I think that these should go in together, as two commits in the same pull
>> request.
>>
>> pyhal.py - similar to the other python component pyhal.py uses the ctypes
>> > python library to interface with hal, which is significantly less code
>> than
>> > the halmodule.cc python wrapper that currently exists.
>> >
>>
>> Is this necessary for the hal_port code to work? Is this a replacement for
>> halmodule.cc or do we end up with both?
>> I think that, unless it is an integral part of your hal_port, this should
>> be a separate pull request and discussion.
>>
>> laserpower.comp - allows vector control of a laser, scaling power during a
>> > move and has no limitations of number of joints a machine can have.
>> >
>> > raster.comp along with a python raster.py programming module to control
>> the
>> > raster, this allows control of the raster component from user space.
>> >
>>
>> Standalone .comps should be no problem, I would roll these in with the
>> main
>> pull request, along with the tests.
>>
>> remapping of M codes to control the raster.py raster programming
>> component.
>>
>>
>> is this part of the sample configs? Or are you saying that you have made
>> more M-codes remappable?
>>
>> Is this an enabler for, or an alternative to, the Mesa "datapainter"?
>>
>> --
>> atp
>> "A motorcycle is a bicycle with a pandemonium attachment and is designed
>> for the especial use of mechanical geniuses, daredevils and lunatics."
>> — George Fitch, Atlanta Constitution Newspaper, 1916
>>
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>

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

Re: [Emc-developers] hal_port with documentation

[Curtis Dutton]

I can fix the indenting on hal_lib.c

I'm not opposed to separate changes however I did use the pyhal.py to
create tests for testing hal_port code. pyhal.py is not actually required
for hal_port to function. (Assuming hal_port functions properly)

The halcompile.g doesn't strictly become a requirement until someone wants
to generate a .comp using hal_ports.


I can't say if pyhal.py should replace halmodule.cc.  My first approach was
to try to modify halmodule.cc but it was quite difficult to wrap my head
around which is why I wrote pyhal.py. pyhal.py could potentially replace
halmocdule.cc but I don't know exactly how that would effect existing
components. Is there a performance penalty? Can everything that
halmodule.cc do be done with pyhal.py? I don't know yet.

The remapping of M codes are part of a sample config only. It is an example
to show how I integrated the raster programmer component with the raster
realtime component. There are I'm sure many other ways to do this.


Right now the raster component is a software only version. My actual laser
machine has mesa hardware so I ultimately want to use datapainter instead
of the raster component. I'm sure that the ultimate driver for datapainter
will work in much the same fashion and share some code with the software
raster implementation.



It may be easier to understand if we did this as 2 separate commits.

hal changes
halcompile.g
hal_port tests
pyhal.py


then

laserpower.comp
raster.comp
rasterprogrammer.py
raster tests
as well as the sample config






On Tue, Aug 6, 2019 at 8:35 AM andy pugh  wrote:

> My opinion only: (I am not sure who has the final say on what goes in to
> Master)
>
> On Mon, 5 Aug 2019 at 15:38, Curtis Dutton  wrote:
>
> A HAL_PORT pin allows for a writer component to send many bytes in one
> > operation to a reader component in real time. The PORT pins behave just
> > like any other pin in HAL and can be linked, unlinked etc...
> >
> > In addition to the modifications to make hal ports some other
> modifications
> > and new parts were required.
> >
> > halcompile.g - added port type. Also added (pin,param,variable)_ptr
> macros
> > to allow access to the actual pointer to those values.
>
>
> I think that these should go in together, as two commits in the same pull
> request.
>
> pyhal.py - similar to the other python component pyhal.py uses the ctypes
> > python library to interface with hal, which is significantly less code
> than
> > the halmodule.cc python wrapper that currently exists.
> >
>
> Is this necessary for the hal_port code to work? Is this a replacement for
> halmodule.cc or do we end up with both?
> I think that, unless it is an integral part of your hal_port, this should
> be a separate pull request and discussion.
>
> laserpower.comp - allows vector control of a laser, scaling power during a
> > move and has no limitations of number of joints a machine can have.
> >
> > raster.comp along with a python raster.py programming module to control
> the
> > raster, this allows control of the raster component from user space.
> >
>
> Standalone .comps should be no problem, I would roll these in with the main
> pull request, along with the tests.
>
> remapping of M codes to control the raster.py raster programming component.
>
>
> is this part of the sample configs? Or are you saying that you have made
> more M-codes remappable?
>
> Is this an enabler for, or an alternative to, the Mesa "datapainter"?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is designed
> for the especial use of mechanical geniuses, daredevils and lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

Re: [Emc-developers] hal_port with documentation

[Curtis Dutton]

Here is the rundown from when I started the work.


I retrofitted my laser engraver with linuxcnc. I do both
rastering and vector cutting on my laser, and it is a 4 axis laser as I do
complicated raster and vector cutting on 3D objects.

I found existing solutions out on the web but they weren't quite adequate
for my needs. Because I have a 4 axis laser (XYZA), controlling vector
power using the Z axis was out.  Also my raster files are sometimes 200Mb
and streaming raster data at the servo period rate via gstreamer takes
quite a long time. I also did not want to have a separate raster data file
alongside the gcode file.

To solve these and some other problems I needed a way to pipe data through
the HAL at a rate much greater than what could be achieved with 1 data
point per servo cycle. Thus the HAL_PORT pin type was born. The idea was
taken from machine kit ring buffers.

A HAL_PORT pin allows for a writer component to send many bytes in one
operation to a reader component in real time. The PORT pins behave just
like any other pin in HAL and can be linked, unlinked etc...

In addition to the modifications to make hal ports some other modifications
and new parts were required.

halcompile.g - added port type. Also added (pin,param,variable)_ptr macros
to allow access to the actual pointer to those values.

pyhal.py - similar to the other python component pyhal.py uses the ctypes
python library to interface with hal, which is significantly less code than
the halmodule.cc python wrapper that currently exists.

laserpower.comp - allows vector control of a laser, scaling power during a
move and has no limitations of number of joints a machine can have.

raster.comp along with a python raster.py programming module to control the
raster, this allows control of the raster component from user space.

remapping of M codes to control the raster.py raster programming component.


Included is also some tests
/tests/pyhal   - also tests hal_port implementation
/tests/raster - tests the rastering component and raster.py programming
interface

Included is also a sim config detailing how to implement a laser engraver
with vector and raster support. In /configs/sim/axes/laser


I have been using this in production for about 18 months now. I am open to any
and all suggesstions on how to structure, features, functions, etc.

I also think that the HAL_PORT can be used as a primitive to build or
replace a lot of code. Maybe even NML and other forms of shared memory
magic.

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

[Emc-developers] hal_port with documentation

[Curtis Dutton]

Hi all I know it has been a long time, but I finally finished up
documentation for the hal_port pin type changes that I have been working on.

I initially added this for performing raster work with my laser engraver.
But the port could be used for a lot of things.


Anyhow I'm hoping to get this merged into master now.

What is my next step.

https://github.com/OKComputers/linuxcnc

I just performed a merge of the latest from master this morning.


Thanks,
   Curtis

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

Re: [Emc-developers] Simultaneous 4 axis + new TP

[Curtis Dutton]

Great thanks for the pointers!

On Thu, Mar 14, 2019 at 1:32 PM Robert Ellenberg  wrote:

> Hi Curtis,
>
> There are a few major hurdles to doing rotary axis blending:
>
>1. Blends between circular motions (that also have motion in other axes)
>are not geometrically possible with the blending technique we use
> (circular
>arc segments), except for some special cases. This IS possible with line
>segments, however.
>2. The blend arcs are parameterized using arc length; the distance in
>ABC has to be included in the arc length calculation, or the blends
> won't
>match velocities properly with the segments they're blending. The
> current
>TP assumes in many places that "progress" along a segment means XYZ
> motion,
>and UVWABC motion is indirectly tied to this.
>3. It's difficult to define blend tolerances for ABC motion in a useful
>way. For example, with 4th axis engraving program, the effective blend
>tolerance depends on the diameter of the part.
>
> All that said, a while ago I extended the 2.7 TP to handle 6 linear axes
> (which avoids problem 3, and doesn't try to blend any circular motions).
> The branch is here if you want to try it out:
>
>
> https://github.com/robEllenberg/linuxcnc-mirror/tree/feature/uvw-blending-2.7
>
> This might help if you don't actually need rotary axis motion and can
> pretend your 4th axis is linear.
>
> Best,
> Rob
>
>
> On Thu, Mar 14, 2019 at 12:56 PM Curtis Dutton  wrote:
>
> > I don't mind doing the G93 calculations. The problem for me is no
> lookahead
> > when using x,y,z,a
> >
> > Does anyone know  why n-axis lookahead isn't easy to accomplish with the
> > new TP? (I'm sure its complicated ! :-)
> >
> > On Thu, Mar 14, 2019 at 12:47 PM Gene Heskett 
> > wrote:
> >
> > > On Thursday 14 March 2019 09:12:51 Les Newell wrote:
> > >
> > > > That does not help the trajectory planner lookahead problem. It just
> > > > tries to correct the feed rates for each movement segment.
> > > >
> > > > Les
> > >
> > > No, it doesn't, so in that sense you're correct, Les, but its certainly
> > > one way to solve the problem in terms of production time.  This is
> > > something I encountered about 4 years back when I attempted to make a
> > > ship auger type drill bit on the G0704 while I was building us an
> > > entertainment center.  And again with a similar auger bit when I was
> > > converting part of our front deck to a wheelchair ramp alittle over a
> > > year ago so I could get the missus in and out of the house. In the
> > > latter case I needed it capable of drilling a hole at a low angle into
> > > the side of a 4x4 about 15" high, to anchor it solidly to the deck so I
> > > could drop a 46" tall plastic rail post over it and make the safety
> > > rails on one side of the ramp. Very solid feeling rail, it doesn't move
> > > with my 165 lbs leaning on it as hard as I can.  That was the general
> > > idea.  But it took many many hours with a 1/4" ball nose carving a 3/4"
> > > piece of cold roll that needed sharpening about 4 times a hole.  Cold
> > > roll is not the ideal to make a drill bit from, but it got the job
> done.
> > >
> > > I should have done something like calculating the speed by translating
> it
> > > to radius, then to inches a minute. But TBT, I was much more interested
> > > in getting the job done, between the rapid dulling and time
> > > resharpening, it took about a day for each of the 3 posts to get them
> > > planted in a puddle of tightbond. Needless to say, I downloaded this
> > > conversion utility. On of the things I intend to do with this big
> gantry
> > > is make a copy of a thumbhole gunstock I carved by hand for a 50 cal BP
> > > rifle.  Someday I'd like to find some purtier Maple. It shoots very
> well
> > > the way it is.
> > >
> > > My thanks to the author, apparently Shawn E. Gano.
> > >
> > > > > https://www.ganotechnologies.com/cnc/rapidrotary/
> > > >
> > > > ___
> > > > Emc-developers mailing list
> > > > Emc-developers@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >
> > >
> > > Cheers, Gene Heskett
> > > --
> > > "There are four boxes to be used in defense of liberty:
> > >  soap, ballot, jury, and ammo. Please use in that order."
&g

Re: [Emc-developers] Simultaneous 4 axis + new TP

[Curtis Dutton]

I don't mind doing the G93 calculations. The problem for me is no lookahead
when using x,y,z,a

Does anyone know  why n-axis lookahead isn't easy to accomplish with the
new TP? (I'm sure its complicated ! :-)

On Thu, Mar 14, 2019 at 12:47 PM Gene Heskett  wrote:

> On Thursday 14 March 2019 09:12:51 Les Newell wrote:
>
> > That does not help the trajectory planner lookahead problem. It just
> > tries to correct the feed rates for each movement segment.
> >
> > Les
>
> No, it doesn't, so in that sense you're correct, Les, but its certainly
> one way to solve the problem in terms of production time.  This is
> something I encountered about 4 years back when I attempted to make a
> ship auger type drill bit on the G0704 while I was building us an
> entertainment center.  And again with a similar auger bit when I was
> converting part of our front deck to a wheelchair ramp alittle over a
> year ago so I could get the missus in and out of the house. In the
> latter case I needed it capable of drilling a hole at a low angle into
> the side of a 4x4 about 15" high, to anchor it solidly to the deck so I
> could drop a 46" tall plastic rail post over it and make the safety
> rails on one side of the ramp. Very solid feeling rail, it doesn't move
> with my 165 lbs leaning on it as hard as I can.  That was the general
> idea.  But it took many many hours with a 1/4" ball nose carving a 3/4"
> piece of cold roll that needed sharpening about 4 times a hole.  Cold
> roll is not the ideal to make a drill bit from, but it got the job done.
>
> I should have done something like calculating the speed by translating it
> to radius, then to inches a minute. But TBT, I was much more interested
> in getting the job done, between the rapid dulling and time
> resharpening, it took about a day for each of the 3 posts to get them
> planted in a puddle of tightbond. Needless to say, I downloaded this
> conversion utility. On of the things I intend to do with this big gantry
> is make a copy of a thumbhole gunstock I carved by hand for a 50 cal BP
> rifle.  Someday I'd like to find some purtier Maple. It shoots very well
> the way it is.
>
> My thanks to the author, apparently Shawn E. Gano.
>
> > > https://www.ganotechnologies.com/cnc/rapidrotary/
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
> 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-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

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

[Emc-developers] Simultaneous 4 axis + new TP

[Curtis Dutton]

 I posted a while ago about adding software laser rastering to linuxcnc.
I'm close to getting the documentation finished so I can get a pull request
for that.

I've recently begun to implement 4 axis simultaneous laser engraving using
G93 inverse time feed. I think I remember reading that the NEW TP doesn't
work when using more than the XYZ axis.

While laser engraving, keeping the speed of the laser as constant as
possible is important.

When the machine gets to a section with many small moves it slows way
down.  Even with straight G64 it is too slow.

Does anyone know about plans for getting the new TP to work with > 3 axis?
I'm not opposed to beginning some of this work if anyone has some pointers?

Thanks,
   Curtis

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

Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Curtis Dutton]

Ok makes sense. I found the datapainter.vhd in the hostmot2 source code
downloaded from mesanet. Doesn't look like it is in the linuxcnc git yet.

On Tue, Jun 26, 2018 at 11:31 AM, andy pugh  wrote:

> On 26 June 2018 at 02:30, Curtis Dutton  wrote:
> > Peter that sounds great. Can I get some links into the relevant pieces?
> I'm
> > willing to work on this, and add to the hm2 driver, do some testing and
> get
> > something going after I finish my man pages. I have a 6i25 and a smart
> > serial IO card in my laser so I can test as I develop.
>
> I think this is unrelated to the smart-serial stream datatype. (So
> your smart-serial board is not relevant)
>
> The files that would need to be altered would be the same ones as were
> altered to add led support (I choose that one as being a very simple
> patch for a very simple feature).
>
> https://github.com/LinuxCNC/linuxcnc/commit/920b18a1e3c278c30ab5b99ad0e441
> fbbc2010b9
>
> Basically a new driver file, adding that to the makefile and a few
> changes in hostmot2.c / .h  to recognise the tags and to know what to
> do with them.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Curtis Dutton]

Peter that sounds great. Can I get some links into the relevant pieces? I'm
willing to work on this, and add to the hm2 driver, do some testing and get
something going after I finish my man pages. I have a 6i25 and a smart
serial IO card in my laser so I can test as I develop.

On Mon, Jun 25, 2018 at 6:23 PM Peter C. Wallace  wrote:

> On Mon, 25 Jun 2018, Curtis Dutton wrote:
>
> > Date: Mon, 25 Jun 2018 10:24:26 -0400
> > From: Curtis Dutton 
> > Reply-To: EMC developers 
> > To: EMC developers 
> > Subject: Re: [Emc-developers] Pre-Pull Request Review: Better laser
> engraver
> > support + new HAL pin type "PORT"
> >
> > Andy,
> >I will look into this. I believe I had a conversation with Peter a while
> >back about getting a raster into Mesa cards. I plan on pursuing that.
> Right
> >now I have my servo thread rate jacked up higher on my laser to get a
> >little more detail. A hardware version is a must for an industrial grade
> >high speed engraver.
> >
> >This stream type would be our way into programming a hardware raster.
> >
>
> I do have firmware for this now = DataPainter module
>
> This is a device similar to our stepgen hardware but instead of outputing
> steps, it outputs bits or 8 bit PWM at the requested rate. The data comes
> from
> a small FIFO (32 deep by 32 wide) so can contain 1024 bits or 128 PWM
> bytes.
> If the host keeps the FIFO full and you allow 1/2 depletion, this gives
> you a
> 512 KHz maximum bit data rate at 1 KHz servo thread or a 64 Khz analog
> data
> rate using PWM. The stepgen arrangement allows "position locking" the data
> stream to an axis, encoder, clock, calculated length, etc via PID to a
> small
> fraction of a bit time. A larger FIFO could be added if higher data rates
> were
> required (up to 10 MHz or so)
>
> There are start and stop compare registers for start of line and line end
> raster data gating (so no fill data is needed)
>
> The bad news is that it is untested other tha basic data tests and that
> there
> is no hm2 driver for it yet (but there is a register map on the latest hm2
> source)
>
>
> Peter Wallace
> Mesa Electronics
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Curtis Dutton]

Andy,
I will look into this. I believe I had a conversation with Peter a while
back about getting a raster into Mesa cards. I plan on pursuing that. Right
now I have my servo thread rate jacked up higher on my laser to get a
little more detail. A hardware version is a must for an industrial grade
high speed engraver.

This stream type would be our way into programming a hardware raster.

On Mon, Jun 25, 2018 at 7:33 AM, andy pugh  wrote:

> On 25 June 2018 at 01:41, Curtis Dutton  wrote:
>
> > A HAL_PORT pin allows for a writer component to send many bytes in one
> > operation to a reader component in real time.
>
> The Mesa Smart-Serial protocol defines a "stream" data type:
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/
> drivers/mesa-hostmot2/sserial.h#L79
>
> But the HAL driver currently does nothing with it:
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/
> drivers/mesa-hostmot2/sserial.c#L420
>
> It is probably worth trying to keep these compatible, as I think that
> they have the same intent.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Curtis Dutton]

Jeff,

You are correct. The hal port operates at a lower level than hal_stream
calls. It is a byte stream, untyped and asynchronous in that a write or
read from the port can consume up to the buffer size of the port in a
single period.

So you could build a sampler, or hal stream on top of a hal port.

I will write up some manpages next. I've never done that before so I'll
have to bone up on them.

The place where ports are allocated is halcmd_commands.c line 687. That was
the easiest place I could find to do it. That code should probably be in
hal_lib.c and just be called by hal command.

On Sun, Jun 24, 2018 at 9:38 PM, Jeff Epler  wrote:

> This is exciting, thank you.
>
> Can you please mention how this compares/contrasts with
> streamer/sampler, which have been factored into hal_stream_XXX API calls
> in our master branch?
>
> From what I can see,
>  - hal "streams" are typed
>  - hal "streams" are agreed on by allocating small integers, not names
>  - hal "streams" storage are outside of the primary HAL shared memory area
>
> .. it looks like
>  - hal "ports" are untyped (byte oriented)
>  - hal "ports" are named
>  - hal "ports" storage are inside the primary HAL shared memory area
>
> I didn't actually spot the implementation of 'halcmd portsize', just the
> addition of it to halcmd's help message
> +printf("  portsizeGet/Set the buffer size of a port
> signal\n");
>
> I would love it if there were manpages for these new functions.  You can
> write manpages in good old fashioned roff style in docs/man/man3/*.3hal or
> in more modern asciidoc style in docs/src/man/man3/*.txt.  Ask if you
> need help with markup or Makefiles, some (Sub)makefile might be needed
> for asciidoc pages.
>
> Jeff
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Curtis Dutton]

Last year I retrofitted my laser engraver with linuxcnc. I do both
rastering and vector cutting on my laser, and it is a 4 axis laser as I do
complicated raster and vector cutting on 3D objects.

I found existing solutions out on the web but they weren't quite adequate
for my needs. Because I have a 4 axis laser (XYZA), controlling vector
power using the Z axis was out.  Also my raster files are sometimes 200Mb
and streaming raster data at the servo period rate via gstreamer takes
quite a long time. I also did not want to have a separate raster data file
alongside the gcode file.

To solve these and some other problems I needed a way to pipe data through
the HAL at a rate much greater than what could be achieved with 1 data
point per servo cycle. Thus the HAL_PORT pin type was born. The idea was
taken from machine kit ring buffers.

A HAL_PORT pin allows for a writer component to send many bytes in one
operation to a reader component in real time. The PORT pins behave just
like any other pin in HAL and can be linked, unlinked etc...

In addition to the modifications to make hal ports some other modifications
and new parts were required.

halcompile.g - added port type. Also added (pin,param,variable)_ptr macros
to allow access to the actual pointer to those values.

pyhal.py - similar to the other python component pyhal.py uses the ctypes
python library to interface with hal, which is significantly less code than
the halmodule.cc python wrapper that currently exists.

laserpower.comp - allows vector control of a laser, scaling power during a
move and has no limitations of number of joints a machine can have.

raster.comp along with a python raster.py programming module to control the
raster, this allows control of the raster component from user space.

remapping of M codes to control the raster.py raster programming component.


Included is also some tests
/tests/pyhal   - also tests hal_port implementation
/tests/raster - tests the rastering component and raster.py programming
interface

Included is also a sim config detailing how to implement a laser engraver
with vector and raster support. In /configs/sim/axes/laser


I have been using this in production for a few months now. I am open to any
and all suggesstions on how to structure, features, functions, etc.

I also think that the HAL_PORT can be used as a primitive to build or
replace a lot of code. Maybe even NML and other forms of shared memory
magic.

Eventually I would like to get this merged into master. I'm open to doing
this in an incremental type fashion so as not to disturb too much at one
time. This is my first "PULL request" with linuxcnc so forgive my ignorance
with regards to this process.

Link to commit, merged with latest master

https://github.com/OKComputers/linuxcnc/commit/0afff760caa3f96d47d9934dc4d07765d40f2591

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

[Emc-developers] halcompile error /usr/bin/x86_64-linux-gnu-ld: cannot find -lieee

[Curtis Dutton]

I'm encountering this error while trying to halcompile a user component.

Branch: Master
Running in place

Currently on Ubuntu 18.04 LTS


Even trying to compile rand.comp example from the halcompiler documentation
gives me this error.

Curiously I can run

halcompile rand.comp

then

halcompile --compile rand.c


and everything builds correctly.

I can also remove the -mieee-fp flag from the command line that halcompile
--compile rand.comp is using and it will build as well.


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

Re: [Emc-developers] RFC: Retire git.linuxcnc.org and move primary git to GitHub

[Curtis Dutton]

Goood!

On Thu, May 18, 2017 at 1:24 PM, James Waples  wrote:

> Github has a pretty good code search and viewer. Is there something
> fundamentally missing from it that the current system has? I don't use it a
> great deal so there may be areas lacking in functionality.
>
> On Thu, 18 May 2017, 18:22 Jon Elson,  wrote:
>
> > On 05/18/2017 02:01 AM, andy pugh wrote:
> > > On 18 May 2017 at 04:08, Jeff Epler  wrote:
> > >> How do developers of LinuxCNC feel about the idea of moving the
> > >> primary git hosting from git.linuxcnc.org to GitHub?
> > > One minor problem with this is that it becomes impossible to search
> > > the source code when away from one's git repositories (for example
> > > during lunch hour at work). I do this quite a lot when looking for
> > > answers to forum queries.
> > >
> > >
> > Oh, this is BIG!  (Thanks, Andy!)  I use the git web
> > interface ALL THE TIME to check some little bit of code to
> > answer a user's question.  Often it is looking at a sample
> > config file, but also for other things.  I'd be pretty
> > unhappy if the git web interface were to go away!  (There
> > might be some way we could provide such an interface
> > ourselves, but I wouldn't know how.)
> >
> > Jon
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] M0 from subrouting in axis MDI mode

[Curtis Dutton]

I'm trying to utilize a loop and a pause in a tool length setting
subroutine for my cnc router.

Basically is probes for a tool length, then pauses with M0 to allow the
operator to change the stickout length and then loops if the tool does not
have enough stick-out.

I typically call the subroutine from MDI mode.


The subroutine works fine if called from a normal g-code file that is
loaded by axis and executed.

However if I run the code from the MDI is goes haywire. It seems to jump to
a different location in the subroutine instead of directly after the M0.

Also the MDI in axis seems to stay active (which is where I am calling the
subroutine from)


I can work on a repro if needed.


Anyone run into this or have an idea where to look? I'm willing to try to
debug and fix the code.


Thanks,
  Curt
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] DISCUSS: Merge the "joints-axes" project to master branch

[Curtis Dutton]

Also agree. I've been using it over a year in production with axis gui.
It's worked very well for us.

On Sat, Jun 11, 2016 at 12:58 PM, John Thornton  wrote:

> This will be awesome. Not using JA as long as Andy but I really like how
> it works for a gantry machine.
>
> JT
>
>
> On 6/10/2016 9:01 PM, Jeff Epler wrote:
> > I propose that we vote the following items at the next IRC meeting
> > (Saturday, June 25, 2016-06-25T1600Z):
> >
> > That we
> >   * Thank all developers who have contributed to the joints-axes project,
> > but particularly Dewey Garrett, Michael Geszkiewicz, Alex Joni, and
> > Andy Pugh for their major contributions
> >   * Rebase and then merge the most current "joints-axes" branch to the
> > linuxcnc.org master branch
> >   * Recommend to developers and to release manager Moses McKnight
> > to shift the emphasis of master branch development to stability
> > rather than new features, so that we can release "2.7+1" with JA
> > features sooner rather than later
> >
> > We haven't held an IRC meeting for quite some time, so if you are
> > unfamiliar with the process (I am!) you can read about it on our wiki:
> >  http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC
> > The next step is to discuss the merits of the proposal in this mailing
> > list prior to the IRC meeting and vote.
> >
> > If you are unfamiliar with "joints-axes", it is a project to improve how
> > LinuxCNC handles machines which do not have a simple 1-to-1
> > correspondence between motors and axis letters.  For example, a gantry
> > with 2 motors on the "Y" axis works much better with the new features
> > that "joints-axes" adds: you can jog any axis incrementally, and apply
> > soft limits to axes.  Users of more exotic machines like the "linear
> > delta" will also see improvements.
> >
> > Documentation for this branch is online, particularly conversion
> > instructions for .ini and .hal files:
> >
> http://linuxcnc.org/docs/ja/html/getting-started/updating-linuxcnc.html#_hal_changes_updates_for_joints_axes
> >
> > If you are aware of regressions in the joints-axes branch, I encourage
> > you to document them with github issues as soon as possible, and request
> > that we tag them with the (just added) joints-axes label so we can track
> > them.
> >
> > Jeff
> >
> >
> --
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports.
> https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Joints_Axes

[Curtis Dutton]

I've been using joints axes for about a year now. I've managed to merge
master into it recently to pick up all of the latest trajectory planner
changes. I'm using a gantry machine with 2 X-AXIS servos, and an indexer
via gantrykins. I've been meaning to try to improve it as I can, but my
time has been severely limited and it is a big project.

I'm all for the merge myself. But there will be a rough period as everyone
scrambles to try and fix all of the other issues that users will find. Its
a breaking change, and very worthwhile in my opinion, but there will be
pain for users, there is no way to avoid that.



On Mon, Sep 28, 2015 at 8:13 PM, EBo  wrote:

> On Sep 28 2015 6:00 PM, Chris Morley wrote:
> > ...
> > Well we force people all the time - that's how we more forward.
> > switching to debian from ubuntu forced me to do work.
> > any changes to config forces me to do work on stepconf or pncconf.
> > Changes to hostmot2 usually forces me to do work.
> > force is a strong word but I wasn't sure what word fit properly.
>
> cattle-prod (ahem) how about motivation?
>
>
> --
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
--
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] joints_axes8

[Curtis Dutton]

Marius,

Q1. I'm sorry to say I don't know. I do remember that thread that you
started. What did Rob the TP author have to say about that?

For Q2, the motoin velocity is indeed limited to the definition of the
joint speeds in non-trivial kins. During configuration you specify
speed/accel limits for each axis and each joint. It appears that while
jogging in joint mode, you get the joint defined speed limits, and in world
mode you get the axis defined speed limits.


On Sat, Jul 25, 2015 at 6:13 AM, Marius Alksnys marius.alks...@gmail.com
wrote:

 Curtis,

 great plans! I have two questions though:
 Question 1.
 Is there anything better in TP than main branch in respect to
 simultaneous motion in multiple axes?

 Now at least with trivial kins a motion with any from XYZ + any from ABC
 works in a manner to be able to stop ABC at the end of current or next G
 code line.

 I raised it in earlier thread Rotary axis motion too slow. In that
 machine and its typical application G-code machining time reduced in
 times after I exchanged Y and A axes in LinuxCNC. (Normally linear Y is
 steady and rotary A is revolving fast with Z fast moves and slow X
 move). People who look at the machine now are amazed how fast it works
 :) But the workaround is not comfortable.

 Question 2. Is trajectory motion velocity limited to joints capabilities
 in non-trivial kins?


 On 07/23/2015 04:33 AM, Curtis Dutton wrote:
  I have rebased joints_axes7 onto master and renamed it to joints_axes8.
 I'm
  running it in production and wanted to pick up the latest changes in the
  trajectory planner. I also included a few other commits. It compiles on
  wheezy and all tests appear to pass.
 
  It's available here.
 
  https://github.com/curtdutt/linuxcnc
 
  My next major task will be to address non consecutive axis names defined
  for lathes.
 
  I would like to get these changes merged into master ASAP and i think
 that
  should happen before tackling  homing multiple joints on a single axis
  because linuxcnc currently doesnt do that at this time. So there wouldnt
 be
  a regression by merging.
 
  If anyone has any other things that they think should be fixed before it
  can go into master please let me know as I will try to address those
 issues
  as well.
 
  -Curtis
 
 --
 




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

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

Re: [Emc-developers] joints_axes8

[Curtis Dutton]

I do not have push access yet.

On Thu, Jul 23, 2015 at 12:30 PM, Sebastian Kuzminsky s...@highlab.com
wrote:

 On 7/22/15 7:33 PM, Curtis Dutton wrote:
  I have rebased joints_axes7 onto master and renamed it to joints_axes8.
 I'm
  running it in production and wanted to pick up the latest changes in the
  trajectory planner. I also included a few other commits. It compiles on
  wheezy and all tests appear to pass.
 
  It's available here.
 
  https://github.com/curtdutt/linuxcnc

 Awesome!

 I haven't looked at it in detail yet.  My only comment so far is, please
 only make commits in the joints_axes branch that actually advance the
 joints_axes work.  The vim commit has nothing to do with j_a and would
 be better placed elsewhere.  This will keep things focused and help the
 reviewers.

 I'd like to see the ja8 branch on git.linuxcnc.org, do you have push
 access?


 --
 Sebastian Kuzminsky


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

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

[Emc-developers] joints_axes8

[Curtis Dutton]

I have rebased joints_axes7 onto master and renamed it to joints_axes8. I'm
running it in production and wanted to pick up the latest changes in the
trajectory planner. I also included a few other commits. It compiles on
wheezy and all tests appear to pass.

It's available here.

https://github.com/curtdutt/linuxcnc

My next major task will be to address non consecutive axis names defined
for lathes.

I would like to get these changes merged into master ASAP and i think that
should happen before tackling  homing multiple joints on a single axis
because linuxcnc currently doesnt do that at this time. So there wouldnt be
a regression by merging.

If anyone has any other things that they think should be fixed before it
can go into master please let me know as I will try to address those issues
as well.

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

Re: [Emc-developers] Problems building in place on debian wheezy

[Curtis Dutton]

Is there an example of a config that I can work with to try and fix?

On Fri, Jun 26, 2015 at 5:16 PM, Sebastian Kuzminsky s...@highlab.com
wrote:

 On 6/25/15 12:39 PM, Curtis Dutton wrote:
  Is there a list of issues that need fixed with the joint axis work? Is it
  being considered for mainline integration eventually? Is there a list of
  issues here that needs addressed prior to integration? I've tried to
 reach
  out here to see who wants some help with it, but I get crickets

 I'm interested in merging joints_axes when it's ready.

 The main problem i know about is that it breaks configs with
 non-consecutive axes, such as lathes.


 --
 Sebastian Kuzminsky


 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Problems building in place on debian wheezy

[Curtis Dutton]

Gotcha. I'll take a look at it.

On Sat, Jun 27, 2015 at 12:20 PM, Dave Cole linuxcncro...@gmail.com wrote:

 Seb means that the software joints_axes does not allow a configuration
 for a lathe to operate, since lathes typically have two axes X and Z,
 but no Y axis.
 There are lathe configurations (ini and hal files)  in the examples.
 You would have to go back to the joints_axes version and figure out why
 that is occurring and then fix that.

 Dave


 On 6/27/2015 9:50 AM, Curtis Dutton wrote:
  Is there an example of a config that I can work with to try and fix?
 
  On Fri, Jun 26, 2015 at 5:16 PM, Sebastian Kuzminsky s...@highlab.com
  wrote:
 
  On 6/25/15 12:39 PM, Curtis Dutton wrote:
  Is there a list of issues that need fixed with the joint axis work? Is
 it
  being considered for mainline integration eventually? Is there a list
 of
  issues here that needs addressed prior to integration? I've tried to
  reach
  out here to see who wants some help with it, but I get crickets
  I'm interested in merging joints_axes when it's ready.
 
  The main problem i know about is that it breaks configs with
  non-consecutive axes, such as lathes.
 
 
  --
  Sebastian Kuzminsky
 
 
 
 --
  Monitor 25 network devices or servers for free with OpManager!
  OpManager is web-based network management software that monitors
  network devices and physical  virtual servers, alerts via email  sms
  for fault. Monitor 25 devices for free with no restriction. Download now
  http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers
 
 
 --
  Monitor 25 network devices or servers for free with OpManager!
  OpManager is web-based network management software that monitors
  network devices and physical  virtual servers, alerts via email  sms
  for fault. Monitor 25 devices for free with no restriction. Download now
  http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers

 ---
 This email has been checked for viruses by Avast antivirus software.
 https://www.avast.com/antivirus



 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Problems building in place on debian wheezy

[Curtis Dutton]

I remember reading some discussions about the gantry homing issue. For me
my gantry is flexible enough just to have each joint home simutaneously
with just a little bit of racking. I home with a limit switches and
indexes. But there is definitly some slight racking that occurs before the
post-homing positions are reached.

What do you imagine would be the proper way in which to home without
racking.

Because it is very difficult to get limits and index positions identical
there would need to be a limit_switch_offset between the two joints and or
an index_pulse_offset for each joint as well.

For my particular case with my gantry, it may look like this. Probably
exaggerated.

A -[INDEX][LIMIT]


B
-[INDEX][LIMIT]

Ideally both motors would turn at the same rate and work together to find
each others limits but it would seem impossible in this case for the lower
joint to ever reach its limit switch assuming the gantry is not allowed to
rack.

I think in this case it would be better to use only 1 limit switch for
homing, and then have the gantry walk back until it hits it's first index,
remember that location for joint_A, then continue walking until B finds its
index, at which point they would be synced and could then continue on to
their HOME location simultaneously, which when configured properly would
not cause racking.

Probably a similar idea to what has been discussed already.

-Curt

On Thu, Jun 25, 2015 at 3:05 PM, Moses McKnight mo...@texband.net wrote:

 Hi Curtis,

 I think the branch has not seen much activity for a while - everyone is
 working
 on other projects.  But, I have a definite interest and hope to get some
 time to
 look at it soon.

 I believe what has been normally happening instead of merging is that the
 joints_axisN branch has been duplicated into a new branch named
 joints_axisN+1,
 and that branch is then rebased on master.  I'm not sure I understand all
 the
 reasoning behind that right now, but someone else can explain I'm sure.

 I don't know of a list of issues, but one is that there needs to be
 support for
 gantry homing to two home switches.

 You might ask on IRC in the #linuxcnc-devel channel as well.

 Moses

 On 06/25/2015 01:39 PM, Curtis Dutton wrote:
  I'm not sure why it was not building for myself.
 
  Either way I did successfully merge master into joint_axis7 and am
 running
  without any issues.
 
  Is there a list of issues that need fixed with the joint axis work? Is it
  being considered for mainline integration eventually? Is there a list of
  issues here that needs addressed prior to integration? I've tried to
 reach
  out here to see who wants some help with it, but I get crickets
 
  On Thu, Jun 25, 2015 at 12:25 PM, Sebastian Kuzminsky s...@highlab.com
  wrote:
 
  On 06/25/2015 08:21 AM, Curtis Dutton wrote:
  Ok so I was able to build and run master correctly. That is sorted out!
 
  But the rub is I'm running joints_axis7 since I have a gantry machine
  with
  dual motors. So I decided to merge master into joints_axis7.
 
  joints_axes7 builds fine on Wheezy.  No merge needed.
 
 
  --
  Sebastian Kuzminsky
 
 
 
 --
  Monitor 25 network devices or servers for free with OpManager!
  OpManager is web-based network management software that monitors
  network devices and physical  virtual servers, alerts via email  sms
  for fault. Monitor 25 devices for free with no restriction. Download now
  http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers
 
 
 --
  Monitor 25 network devices or servers for free with OpManager!
  OpManager is web-based network management software that monitors
  network devices and physical  virtual servers, alerts via email  sms
  for fault. Monitor 25 devices for free with no restriction. Download now
  http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers
 


 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https

Re: [Emc-developers] Problems building in place on debian wheezy

[Curtis Dutton]

I found it from the machonekit site. Where should I get the standard kernel
from? I had a hard time locating one.
On Jun 24, 2015 12:15 PM, Sebastian Kuzminsky s...@highlab.com wrote:

 On 6/24/15 9:20 AM, Curtis Dutton wrote:
  ./configure completes succesfully but make isn't making it.
 
  Now my kernel is '3.8-1-rtai.x86-amd64'

 This is a non-standard RTAI kernel that isn't shipped by LinuxCNC.  I
 bet the problem is with the integration of that realtime kernel and the
 LinuxCNC build system.

 Where did you get the kernel?


 --
 Sebastian Kuzminsky


 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Problems building in place on debian wheezy

[Curtis Dutton]

I'm going to try and build the master branch to see if the same error
occurs.


Thanks for your help,
  Curt

On Wed, Jun 24, 2015 at 1:18 PM, Curtis Dutton curtd...@gmail.com wrote:

 Ok I have the sources and packages straightened out.

 Now back to building with --with-realtime=uspace

 I get this error while building.


 Linking ../rtlib/abs.so
 ld -d -r -o objects/abs.tmp
 ld: no input files
 make: *** [../rtlib/abs.so] Error 1


 On Wed, Jun 24, 2015 at 12:33 PM, Sebastian Kuzminsky s...@highlab.com
 wrote:

 On 6/24/15 10:26 AM, Curtis Dutton wrote:
  I found it from the machonekit site. Where should I get the standard
 kernel
  from? I had a hard time locating one.

 The easy way to install LinuxCNC is to use our Install Image.  The docs
 have the instructions for fetching and using it:


 http://linuxcnc.org/docs/2.6/html/common/Getting_LinuxCNC.html#_getting_linuxcnc


 If you want to install Wheezy using the upstream debian.org installer
 then add LinuxCNC on top of that by hand, we have instructions for that
 here:


 http://linuxcnc.org/docs/2.7/html/getting-started/Getting-LinuxCNC.html#_alternate_install_methods

 (This Alternate Install Methods documentation is not in 2.6, it was
 added for 2.7, but the RTAI kernels are the same.)


 --
 Sebastian Kuzminsky


 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers



--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Status of cradek/joints_axes7

[Curtis Dutton]

Ok great. Ive been slowly getting my head wrapped around the code and plan
on contributing. We are dead smack in the middle to moving into a new shop.
After that settles down I have a one line fix to get my feet wet.

I do have 2 limit switches on my machine. They have adjustable screws on
them to hit the limits at roughly the same time. The gantry is a little
flexible so the homing hasnt been a problem. I could forsee a feature for
sycronizing joints that are mapped to a single axis since emc is now
aware of those mappings in the ini file. I remember there was a
discussion about that not too long ago.
On May 14, 2015 6:17 PM, Moses McKnight mo...@texband.net wrote:

 I think it is just waiting for people to have time to test and fix it, and
 it
 will go into master at some point.  Other people probably know the status
 better
 than I, and I'm sure bug fixes and help is always welcome!

 The way I understand it they have be doing a rebase instead of merging, and
 creating a new branch with the number at the end incremented by one to do
 the
 rebase in.

 I plan on doing some of that when I get time, especially because I run
 gantry
 machines.  Do you have 2 homes switches on your gantry?

 Moses

 On 05/14/2015 01:00 PM, Curtis Dutton wrote:
  Does anyone know about the status of joints_axes7 branch?
 
 
  Is this a feature set that is planned for merge into master at some time
 in
  the future?
 
  I've been using it for a few months now and I have a little bug fix.
 
  I'm also wondering when it needs a merge from master. I'm willing to help
  contribute to it since it is a huge improvement in usability when using
  gantrykins.
 
 
 
 
  Thanks,
  Curt
 
 --
  One dashboard for servers and applications across Physical-Virtual-Cloud
  Widest out-of-the-box monitoring support with 50+ applications
  Performance metrics, stats and reports that give you Actionable Insights
  Deep dive visibility with transaction tracing using APM Insight.
  http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers
 


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Status of cradek/joints_axes7

[Curtis Dutton]

Does anyone know about the status of joints_axes7 branch?


Is this a feature set that is planned for merge into master at some time in
the future?

I've been using it for a few months now and I have a little bug fix.

I'm also wondering when it needs a merge from master. I'm willing to help
contribute to it since it is a huge improvement in usability when using
gantrykins.




Thanks,
   Curt
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] joints_axes7 branch - jogging dual joint axis issue

[Curtis Dutton]

Jogging with the keyboard.


I've been working with the ja branch successfully, just with gantrykins.

On Mon, Mar 16, 2015 at 6:41 AM, andy pugh bodge...@gmail.com wrote:

 On 14 March 2015 at 18:13, Curtis Dutton curtd...@gmail.com wrote:
  Ok so with Gentrivkins I have the following issue, everything else seems
 to
  work fine. With gantrykins I get the correct jogging behavior.

 I was hoping that someone who is actually familiar with JA would offer
 advice here.

 It sounds almost like gentrivkins is jogging in joint mode, despite
 the fact that it is a trivkins an shouldn't have separate world and
 joint modes.

 How are you jogging? Keyboard? jogwheels to motion or halui pins?

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


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Array Overflow in WJ200

[Curtis Dutton]

I can test it out, I have the hardware and I wrote the initial draft of the
driver.

The problem is that I have never hit this bug yet and I'm not sure how to
reproduce it. I'm running out of master though.

On Fri, Mar 13, 2015 at 10:42 PM, Chris Radek ch...@timeguy.com wrote:

 On Fri, Mar 13, 2015 at 09:32:10PM -0400, Brian wrote:
  Some bounds checking would be a good idea in addition to making the array
  bigger.

 Brian do you have this hardware?  It would be great if you could fix
 and test it.

 Chris


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] joints_axes7 branch - jogging dual joint axis issue

[Curtis Dutton]

Ok so, still using this branch I switched to gantrykins and now things are
working properly. Still have to swtich to world mode, but things like
limits being obeyed and incremental jogging are great.

On Sat, Mar 14, 2015 at 10:50 AM, Curtis Dutton curtd...@gmail.com wrote:

 I have set up a gantry machine with dual drive motors. I started out with
 gantrykins which was terrible and found the joints_axes7 branch.

 It is an XXYZA machine where A is a rotary indexer. Everything homes
 correctly, it follows g-code commands properly etc...

 My only problem is when trying  to jog. If I try to jog the X axis, it
 only moves gantry motor 1. If I try to jog the Y axis, it moves the other
 gantry motor. Jog the Z axis and the y axis moves. Jog the A axis and
 the z axis moves

 What am I doing wrong?

 Thanks,
 Curt


 ini file -
 https://drive.google.com/file/d/0Bz6_8JJkp_lOdUUyRDlNM0ZoMG8/view?usp=sharing

 hal file -
 https://drive.google.com/file/d/0Bz6_8JJkp_lOQTQ0WWNTbVpGYm8/view?usp=sharing
 ​​


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] joints_axes7 branch - jogging dual joint axis issue

[Curtis Dutton]

I have set up a gantry machine with dual drive motors. I started out with
gantrykins which was terrible and found the joints_axes7 branch.

It is an XXYZA machine where A is a rotary indexer. Everything homes
correctly, it follows g-code commands properly etc...

My only problem is when trying  to jog. If I try to jog the X axis, it
only moves gantry motor 1. If I try to jog the Y axis, it moves the other
gantry motor. Jog the Z axis and the y axis moves. Jog the A axis and
the z axis moves

What am I doing wrong?

Thanks,
Curt


ini file -
https://drive.google.com/file/d/0Bz6_8JJkp_lOdUUyRDlNM0ZoMG8/view?usp=sharing

hal file -
https://drive.google.com/file/d/0Bz6_8JJkp_lOQTQ0WWNTbVpGYm8/view?usp=sharing
​​
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] joints_axes7 branch - jogging dual joint axis issue

[Curtis Dutton]

Ok so with Gentrivkins I have the following issue, everything else seems to
work fine. With gantrykins I get the correct jogging behavior.

Everything homes correctly, it follows g-code commands properly etc...

My only problem is when trying  to jog. If I try to jog the X axis, it
only moves gantry motor 1. If I try to jog the Y axis, it moves the other
gantry motor. Jog the Z axis and the y axis moves. Jog the A axis and
the z axis moves

On Sat, Mar 14, 2015 at 1:32 PM, andy pugh bodge...@gmail.com wrote:

 On 14 March 2015 at 15:25, Curtis Dutton curtd...@gmail.com wrote:
  Ok so, still using this branch I switched to gantrykins

 You could try Gentrivkins for a gantry.

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


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

I don't believe it ever was merged.

It is available here...
https://github.com/OKComputers/linuxcnc-mirror/tree/wj200_vfd


If I can help with integration I will. Also a code review and any
suggesstions on things I may be doing wrong would be welcome as well. It
has worked for me well, but I'm sure it can be improved or is missing
features that are desirable.

Thanks,
  Curt


On Thu, May 22, 2014 at 8:41 AM, andy pugh bodge...@gmail.com wrote:

 On 1 July 2013 05:29, Sebastian Kuzminsky s...@highlab.com wrote:
  Thanks for your continued work on this driver.  I hope to merge it into
  master before the 2.6 release branch is made, and have it be included in
  the next official release of LinuxCNC.

 I have seen a few comments to the effect that this driver is in
 pre-2.6, but I can't actually see it.
 Did it ever get merged?


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


 --
 Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
 Instantly run your Selenium tests across 300+ browser/OS combos.
 Get unparalleled scalability from the best Selenium testing platform
 available
 Simple to use. Nothing to install. Get started now for free.
 http://p.sf.net/sfu/SauceLabs
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] circular arc blend beta: milltask (pid 6660) died on signal 11.

[Curtis Dutton]

It has not happened to me again. It was a one time thing so far.

When I'm working with the machine, I copy down .ngc files to a folder on
the cnc controller machine. Then run through them. Often I delete these
files at the end of working with the cnc. I may have left the file open in
Axis, deleted them from the computer, ran my toolchange program, and when
it finished... bang! On the older 2.5 version this would just freeze axis
occasionally. I'm wondering if the beta branch has different code that
faults instead of freezes axis.


On Wed, Jan 22, 2014 at 9:28 PM, Jon Elson el...@pico-systems.com wrote:

 On 01/22/2014 02:04 PM, Sebastian Kuzminsky wrote:
 Oh, signal 11!  I know that one.  It can be caused by bad
 memory or
 cache.  The OP might want to run the memtest86 that at least
 used
 to be included on the live CD.

 Jon


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] circular arc blend beta: milltask (pid 6660) died on signal 11.

[Curtis Dutton]

Does anyone know what may have caused this?

So I'm running the circular arc blend beta from Roberts github repository.
I'm running a build based on commit
8acb5e68a4e9c03b191555f912de53e639576dec


I'm not sure if this is related to circular arc blend or just latest
linuxcnc master code.

Attached is the backtrace. I was running a call (in the command window) o
tool_change call which is a simple program to touch a tool probe after a
manual change. It had just finished that subroutine when milltask died.

Attached is the backtrace.


Thanks,
Curtis


backtrace.6660
Description: Binary data
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Beta release of circular arc blending

[Curtis Dutton]

Robert,

Today I found the time to install 12.04 LTS on my router controller, build
the circular arc blending beta branch and get it running.


Everything seems to be working wonderfully with a dry run. The program that
I tested is a 4.8MB 3d shaping g-code program. On the 2.5 release without
arc blending it takes 38 minutes to run. With circular arc blending it
takes 27 minutes.

To me that is just a HUGE improvement and I cannot say thanks enough for
your work so far! I don't know when else I was able to flip a switch and
get that much improvement in my manufacturing process! Big big time savings
for me. I think these changes will be just as huge for the linuxcnc
community overall and will really help linuxcnc's reputation.

I am a software developer as well, so whenever you need a buddy build,
debugging, help, etc... feel free to ping me. I'll help when I have time.

I'll chirp up again after I make some real cuts tomorrow with any issues I
see in the parts I make.




P.S.
The only issue I had was the first time through the build it was
complaining about not finding cscope. A simple apt-get install did the
truck. I suggest that a check be added to ./configure to alert the user of
its necessity prior to building.



On Wed, Jan 8, 2014 at 5:16 PM, Robert Ellenberg rwe...@gmail.com wrote:

 Hi All,

 After fixing a few persistent but minor issues with arc blending, I think
 the code is ready for beta status. I've pushed a branch on my github fork
 called circular-blend-arc-beta:


 https://github.com/robEllenberg/linuxcnc-mirror/tree/circular-blend-arc-beta

 This branch has code that does not violate velocity or acceleration
 constraints on any of the test programs. As such, it's ready for (carefully
 supervised) hardware testing. Once it's running on a few machines without
 issue, it should be merge-ready for the master branch.

 Thanks again to everyone who's helped out with extensive advice and
 testing!
 -Rob

 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

Ok so I think this code is well enough tested, and the comp files also
includes the documentation.

What do I need to do to get this integrated into the codebase.

I have a branch on github with my changes. I can provide a patch if
necessary. https://github.com/OKComputers/linuxcnc

Thanks,
   Curtis


On Thu, May 23, 2013 at 6:27 AM, John Thornton bjt...@gmail.com wrote:

 If you need help on the man page or adding this to the Integrators
 Manual just let me know.

 JT

 On 5/20/2013 8:50 PM, Curtis Dutton wrote:
  Ok I have the driver pretty much completed and it has been working well
 for
  a week now. It can now take command line arguments to control the modbus
  serial connection parameters.
 
  Now I'd like to add a manpage for the driver and any other documentation
  where appropriate. I need some guidance on what documentation to add and
  where to add it.
 
 
  Thanks in advance,
   Curtis
 
 
 
 
 
 
  On Thu, May 16, 2013 at 8:02 AM, Curtis Dutton curtd...@gmail.com
 wrote:
 
  I plan on using the userinit section for parsing command line options.
  This is where I plan to allow users to specify modbus connection
  parameters. Is that the preferred way to configure the driver?
 
 
  I did not intend to check in wj200_vfd.c. I looked at my repository on
  github, and it doesn't seem to be checked in.
 
  Thanks for the bugfixing.
 
  -Curt
 
 
 
  On Wed, May 15, 2013 at 9:22 AM, Sebastian Kuzminsky s...@highlab.com
 wrote:
 
  On 05/15/2013 04:27 AM, andy pugh wrote:
  On 15 May 2013 04:20, Sebastian Kuzminsky s...@highlab.com wrote:
 
  The only comp that sets 'option userinit yes' is bldc, but it doesnt
  set
  'option userspace yes', so comp doesn't try to call it.
  Which means that I messed up with bldc then.
 
  I will remove that line later (and check that everything still works).
  I took it out as soon as i noticed it.
 
 
  --
  Sebastian Kuzminsky
 
 
 
 --
  AlienVault Unified Security Management (USM) platform delivers complete
  security visibility with the essential security capabilities. Easily
 and
  efficiently configure, manage, and operate all of your security
 controls
  from a single console and one unified framework. Download a free trial.
  http://p.sf.net/sfu/alienvault_d2d
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers
 
 
 
 --
  Try New Relic Now  We'll Send You this Cool Shirt
  New Relic is the only SaaS-based application performance monitoring
 service
  that delivers powerful full stack analytics. Optimize and monitor your
  browser, app,  servers with just a few lines of code. Try New Relic
  and get this awesome Nerd Life shirt!
 http://p.sf.net/sfu/newrelic_d2d_may
  ___
  Emc-developers mailing list
  Emc-developers@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/emc-developers



 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

I plan on using the userinit section for parsing command line options. This
is where I plan to allow users to specify modbus connection parameters. Is
that the preferred way to configure the driver?


I did not intend to check in wj200_vfd.c. I looked at my repository on
github, and it doesn't seem to be checked in.

Thanks for the bugfixing.

-Curt



On Wed, May 15, 2013 at 9:22 AM, Sebastian Kuzminsky s...@highlab.comwrote:

 On 05/15/2013 04:27 AM, andy pugh wrote:
  On 15 May 2013 04:20, Sebastian Kuzminsky s...@highlab.com wrote:
 
  The only comp that sets 'option userinit yes' is bldc, but it doesnt set
  'option userspace yes', so comp doesn't try to call it.
 
  Which means that I messed up with bldc then.
 
  I will remove that line later (and check that everything still works).

 I took it out as soon as i noticed it.


 --
 Sebastian Kuzminsky


 --
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

Ok I have integrated the wj200_vfd driver into linuxcnc
src/hal/user_comps/wj200_vfd

The repository is available at https://github.com/OKComputers/linuxcnc

I have not yet completed the driver, I need to add command line option
parsing to set the modbus communication parameters. However I have run the
driver on my own machine for about 10 hours of operation now, and it is
performing nicely.


During my work, I discovered a bug in the comp.py program. The problem is
option userinit yes generates code that will not compile.

 Here is a link to the commit that has the fix

Is there anyone out there that can integrate that change for me? I can send
a patch or do whatever is needed to help out...

https://github.com/OKComputers/linuxcnc/commit/782e98456d278be90b7198ce8b552e824748f5b0


Thanks,
Curtis


On Wed, May 8, 2013 at 6:54 PM, Sebastian Kuzminsky s...@highlab.com wrote:

 On May 8, 2013, at 16:46 , Curtis Dutton wrote:

  Are there any pointers on how to integrate my .comp file into the
 Makefile
  system? Even examples elsewhere in the source tree would be useful.

 You just put your .comp in src/hal/components.  Add a test if you're
 feeling frisky.

 Check out commit a307a69fc19df523668f191f21061f9d5457fef9 for an example.

 Hmm, you link against libmodbus, right?  That might make things more
 complicated…

 --
 Sebastian Kuzminsky



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their applications. This 200-page book is written by three acclaimed
 leaders in the field. The early access version is available now.
 Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

Thanks for the feedback. Very useful!

I will handle integrating this into the linuxcnc source tree after I get
things cleaned up, tested, and get the code production worthy. I'll also
move all of the code into the comp file as suggested by Sebastian.



As far as capturing output, I'll just write any errors encountered to
stderr. That is perfectly fine as far as I'm concerned. I just had a hard
time finding out where the linuxcnc logs were located. I couldn't find them
in the documentation via search, or in the wiki either.


As far as the watchdog goes, It just didn't occur to me. I think that a
watchdog is a much better solution than monitoring the exit code of the
user component. Simply because it is an explicit mechanism. No matter how
perfect the component may be, it can still have an error, and start
behaving erratically. The watchdog is going to have a more reliable take on
the behavior of the user component and it is easier to understand when
someone else comes in and looks at the .hal file for troubleshooting.

Thanks a bunch,
Curt


On Tue, May 7, 2013 at 11:40 AM, Sebastian Kuzminsky s...@highlab.comwrote:

 On May 7, 2013, at 08:43 , Curtis Dutton wrote:

  I have a preliminary WJ200 modbus inverter driver that I've written,
 based
  upon other modbus drivers I have seen from the VFD wiki page.
 
  The source code so far is posted at
 https://github.com/OKComputers/wj200vfd

 Awesome!

 Some feedback:

 You have two commits in a stand-alone repository, it would be easier for
 us to integrate with the main linuxcnc code if your commits were based on
 the linuxcnc git repo at git://git.linuxcnc.org/git/linuxcnc.git (master
 branch).  This would also let you integrate with the linuxcnc build system
 instead of making your own (go.sh).

 It looks like you have a .c file that provides interface functions to the
 wj200, a .comp to connect the device to HAL, plus a bunch of .c programs to
 test different parts of the C interface and perform specific actions with
 the wj200.  The .c utils probably don't belong in linuxcnc (their
 functionality should be exported to HAL by the .comp driver).  That would
 let you put the helper functions into the .comp file and simplify your
 build.

 The .comp file belongs in src/hal/user_comps.


  How do I report an error from user_mainloop? If the driver crashes, or
  errors out, how do I get the hal to automatically ESTOP and fail.  The
  usermode comp does not seem to be able to report an error. The behavior
 so
  far, seems to be that the pins and parameters just dissapear from the hal
  if the driver exits for any reason.

 That is correct.  It's not great, but that's the way it currently is.  The
 way to have a failure of the driver cause an estop is to export a
 'heartbeat' pin, and connect that to a watchdog component, and have
 watchdog failure cause an estop.  This works mostly, but it's not currently
 well documented or widely used.


  Also, when logging information, does the hal watch stdout and stderr and
  pass information along somewhere? I'm not sure if there is a page
 somewhere
  that shows me how to do logging.


 I think if you print to stdout/stderr, it'll show up in the main
 linuxcnc.print and linuxcnc.debug files, respectively.  These live in /tmp,
 and they have random characters appended to the name so they're a little
 awkward to find.  Logging is another area of linuxcnc that's a but wonky
 still…  Looks like you're finding all our shortcomings!


 --
 Sebastian Kuzminsky



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their applications. This 200-page book is written by three acclaimed
 leaders in the field. The early access version is available now.
 Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

The architecture of the future logging systems sounds nice.

Are there any pointers on how to integrate my .comp file into the Makefile
system? Even examples elsewhere in the source tree would be useful.




On Wed, May 8, 2013 at 4:56 PM, Michael Haberler mai...@mah.priv.at wrote:


 Am 08.05.2013 um 17:09 schrieb Curtis Dutton curtd...@gmail.com:

  As far as capturing output, I'll just write any errors encountered to
  stderr. That is perfectly fine as far as I'm concerned. I just had a hard
  time finding out where the linuxcnc logs were located. I couldn't find
 them
  in the documentation via search, or in the wiki either.

 It's a good example of one in a long list of cleanups due, as LinuxCNC
 sports a, hm, 'organically grown architecture' here ;)

 we currently have:

 in an RT build:
 - RT component messages go to the kernel log (printk)
 - however messages generated in the motion module, which happen to be
 funnelled to milltask, the coordinator, have the potential to wind up on a
 UI
 - messages by userland HAL components (like you VFD driver) wind up in
 stderr which goes to a log file
 - a 'message level' applies to all RT components alike, however message
 levels for userland components are all one-per-component

 however, in a 'sim' build (and those rules apply to early Xenomai- and
 RT-Preempt versions as well) we have:
 - RT and userland component messages go to stderr (rt-preempt) and a
 xenomai-specific destination (xenomai)
 - exceptions for motion as above

 meaning: non-motion messages delivered to UI's: not possible; rest of
 them: make sure you know where to dig

 --

 the code base which should become available later this year addresses this
 as follows:

 - there is a single error message queue accessible by all components,
 living in a shared memory segment, and independent of RTOS style and
 component style
 - all messages are tagged by origin and level
 - there are two message levels; one for RT components, and one for the
 rest of them, to determine disposition
 - disposition happens in a demon which receives all messages and may
 log/forward as needed - for instance to UI's

 - Michael



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their applications. This 200-page book is written by three acclaimed
 leaders in the field. The early access version is available now.
 Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
 ___
 Emc-developers mailing list
 Emc-developers@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-developers

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Hitatchi WJ200 Inverter Driver (using comp)

[Curtis Dutton]

I have a preliminary WJ200 modbus inverter driver that I've written, based
upon other modbus drivers I have seen from the VFD wiki page.

The source code so far is posted at https://github.com/OKComputers/wj200vfd


How do I report an error from user_mainloop? If the driver crashes, or
errors out, how do I get the hal to automatically ESTOP and fail.  The
usermode comp does not seem to be able to report an error. The behavior so
far, seems to be that the pins and parameters just dissapear from the hal
if the driver exits for any reason.


Also, when logging information, does the hal watch stdout and stderr and
pass information along somewhere? I'm not sure if there is a page somewhere
that shows me how to do logging.



Thanks,
Curt



P.S. Once I get it sorted out, I'll be happy to support this driver.
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers