Re: [Emc-developers] The Wiki Certificate might have expired

[Alan Condit via Emc-developers]

Andy,

It works here on my Mac.

Alan

> Date: Fri, 17 May 2024 23:25:41 +0100
> From: andy pugh 
> To: EMC developers 
> Subject: [Emc-developers] The Wiki Certificate might have expired
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> My Mac is really unwilling to visit wiki.linuxcnc.org
> 
> 
> -- 
> 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

Re: [Emc-developers] Found a new show stopper

[Alan Condit via Emc-developers]

Gene,

In the second block of code following the while loop you’re missing some more 
“call”s

o1 while[#50 le 7] ( stop short )
( Enf of MAIN WHILE LOOP )
o5 endif
o6 if [#<_measure> lt 1]
o7 do
o call
o  call (see what its got)
o call (move to it)
(put drill hole call here)
#50 = [#50 +1]
o7 while [#50 le 7]
o6 endif
M2

> On Mar 7, 2024, at 11:20 AM, emc-developers-requ...@lists.sourceforge.net 
> wrote:
> 
> o1 while[#50 le 7] ( stop short )
> ( Enf of MAIN WHILE LOOP )
> o5 endif
> o6 if [#<_measure> lt 1]
> o7 do
> o
> o (see what its got)
> o (move to it)
> (put drill hole call here)
> #50   = [#50 +1]
> o7 while [#50 le 7]
> o6 endif
> M2


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

Re: [Emc-developers] Found a new show stopper

[Alan Condit via Emc-developers]

Gene,

In the second block of code following the while loop you’re missing some more 
“call”s

o1 while[#50 le 7] ( stop short )
( Enf of MAIN WHILE LOOP )
o5 endif
o6 if [#<_measure> lt 1]
o7 do
o call
o  call (see what its got)
o call (move to it)
(put drill hole call here)
#50 = [#50 +1]
o7 while [#50 le 7]
o6 endif
M2

> On Mar 7, 2024, at 11:20 AM, emc-developers-requ...@lists.sourceforge.net 
> wrote:
> 
> o1 while[#50 le 7] ( stop short )
> ( Enf of MAIN WHILE LOOP )
> o5 endif
> o6 if [#<_measure> lt 1]
> o7 do
> o
> o (see what its got)
> o (move to it)
> (put drill hole call here)
> #50   = [#50 +1]
> o7 while [#50 le 7]
> o6 endif
> M2


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

[Emc-developers] spi on Bookworm

[Alan Condit via Emc-developers]

Seb,

Have you had any luck getting spi devices to run on Debian 12 Bookworm?
I got spi-bcm2835 to load on boot but so far I haven’t been able to create any 
spi devices.
I did load spi-tools and api-config runs but won’t create any spi devices for 
me.

Alan

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

Re: [Emc-developers] Downloading of DOCS still an issue

[Alan Condit via Emc-developers]

Gene,

I was able to build linuxcnc on the Pine RockPro64 which is a 3399 chip.

Alan

> 
> Date: Tue, 15 Aug 2023 09:22:52 -0400
> From: gene heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] Downloading of DOCS still an issue
> Message-ID: <08e6b291-69c0-6ff3-3923-2a6c2edc6...@shentel.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
>> Or are you running a 64-bit kernel?
> Not on the rpi4 just yet, its running armhf, but I've a luv affair with 
> bananapi-m5's in my 3d printer stuff. Somewhat faster than a pi, all 4 
> usb ports are usb3, but no radio. $85/copy on amazon. If the pi dies, 
> I'll see if I can rebuild rpspi.ko to run on the 3399 chip.
>> 
> 
> Cheers, Gene Heskett.



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

Re: [Emc-developers] Emc-developers Digest, Vol 207, Issue 18

[Alan Condit via Emc-developers]

If I compare two pointers to the same variable, it seems to me that the two 
pointers should match. It has been too many years of not programming for me to 
be sure. I couldn’t find the function “gpiod_line_bulk_get_line” so I can’t 
really tell what pointer it is returning.

Alan

> On Jul 27, 2023, at 7:23 AM, emc-developers-requ...@lists.sourceforge.net 
> wrote:
> 
> Send Emc-developers mailing list submissions to
>   emc-developers@lists.sourceforge.net
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.sourceforge.net/lists/listinfo/emc-developers
> or, via email, send a message with subject or body 'help' to
>   emc-developers-requ...@lists.sourceforge.net
> 
> You can reach the person managing the list at
>   emc-developers-ow...@lists.sourceforge.net
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Emc-developers digest..."
> 
> 
> Today's Topics:
> 
>   1. gpiod - is it me or is it them? (andy pugh)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 27 Jul 2023 01:24:54 +0100
> From: andy pugh 
> To: EMC developers 
> Subject: [Emc-developers] gpiod - is it me or is it them?
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> I think that I have found a mistake in gpiod
> 
> https://github.com/brgl/libgpiod/blob/master/lib/core.c#L449
> 
> I think that this is comparing two pointers to the same struct. But
> they won;t ever match as they are different variables?
> 
> Or, alternatively, I don;t understand C and it is fine.
> 
> Except it doesn't work
> 
>  printf("Chips line 0 %p %s\n", gpiod_line_get_chip(line0),
> gpiod_chip_name(gpiod_line_get_chip(line0)));
>  printf("Chips line 1 %p %s\n", gpiod_line_get_chip(line1),
> gpiod_chip_name(gpiod_line_get_chip(line1)));
>  printf("Chips line 2 %p %s\n", gpiod_line_get_chip(line2),
> gpiod_chip_name(gpiod_line_get_chip(line2)));
> 
> Returns:
> 
> Chips line 0 0x3f1280 gpiochip0
> Chips line 1 0x3f2af0 gpiochip0
> Chips line 2 0x3f4350 gpiochip0
> 
> 
> 
> -- 
> 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
> 
> 
> 
> --
> 
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> 
> 
> --
> 
> End of Emc-developers Digest, Vol 207, Issue 18
> ***



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

[Emc-developers] 2.9 Release Manager Required.

[Alan Condit]

Andy,

I can’t do it either, but I really appreciate all the help you've given to
LinuxCNC.

I agree that Bullseye would be an appropriate target for the 2.9 release. I
have compiled master for Bullseye and am currently working on compiling
Linux-5.15.76-rt53 on Amd64. I have master running on Linux-5.15.73-rt52
running on my RPi4 but since the merge of the rt stuff in to Linux, I
haven’t been able to successfully build a PREEMPT_RT kernel for either RPi4
or AMD64.

Alan


> Date: Sat, 12 Nov 2022 01:05:30 +
> From: andy pugh 
> To: EMC developers 
> Subject: [Emc-developers] 2.9 Release Manager Required.
> Message-ID:
> <
> can1+yzuvr0ehgqwfzxyqgmaha-my3nj4xfryulm2r1g6src...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I can't do it.
>
> Previously the buildbot was integral to the process, but the buildbot only
> builds for Buster- and I have no control over it.
>
> LinuxCNC is being built into Debian Bookworm, but I have no involvement in
> this process, and no access rights.
>
> Debian Bullseye would be the logical release platform for 2.9. I could set
> up my own build-farm (I have enough hardware) but that would be a lot of
> work in an area in which I have no expertise.
>
> I have asked what the release platform should be, and there wasn't a single
> reply.
>
> I will continue as a user and I will continue to offer my support on
> the forum and mailing lists, I am not going anywhere, but I am both
> ignorant of what the release policy should be and  incapable of performing
> the release manager role with the accesses and expertise that I have.
>
> --
> 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] Problem with PNCConf and dpll

[Alan Condit]

Chris Morley,
It seems to me that there is a problem with PNCConf in master. It uses dpll
for watchdog timer on the Mesa 5i25 but the 5i25 firmware doesn’t support
dpll. Is there a way to change that so that pncconf tests to see if the
user is actually using firmware that supports dpll? Peter said that the pci
boards generally don’t support dpll.

Thanks,
Alan

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

Re: [Emc-developers] bug (new?)in master

[Alan Condit]

Gene,

On line# 157 you have a “{“ following the IF rather than a “[“.

See if fixing that helps?

Alan


> Date: Wed, 21 Sep 2022 17:28:07 -0400
> From: gene heskett 
> To: EMC developers 
> Subject: [Emc-developers] bug (new?)in master
> Message-ID: <4e6ff28a-4d3a-c1d4-1c56-cf3f3f02a...@shentel.net>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Greetings all;
>
> I keep getting a squawk about line 160 on a code reload of this sequence
> in my proggy's main loop:
>
> 157 o01 IF {#<_do100> GT .5]
> 158 o100 CALL (with a trailing comment about whats done in this style)
> 159 M2 (done if do100 true)
> 160 o01 ELSE (assume its been done)
> 161 #<_ztmp>=-4.000
> 162 #<_zbase>=-4.000
> 163 o01 ENDIF
>
> But it runs fine if I put that (comment) on a separate line.
> This is a restriction on comment style I don't recall before recently,
> and is probably used 50 more times in this files 220 or so LOC.
>
> Perhaps the ELSE clause needs looked at, my guess is its ignoring the
> opening (
> of the comment since the error msg quotes the whole comment with both ()
> characters.
>
> Thanks all.
>
> 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, 1940)
> If we desire respect for the law, we must first make the law respectable.
>   - Louis D. Brandeis
> Genes Web page
>
>
> --
>
> Message: 2
> Date: Wed, 21 Sep 2022 21:34:25 + (UTC)
> From: Alec Ari 
> To: EMC developers 
> Subject: Re: [Emc-developers] Time to split 2.9 and master?
> Message-ID: <559060263.609004.1663796065...@mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> To clarify, I wasn't implying it meant anything different. The SIGFPE
> problem is fixed anyway so disregard my previous email.
>
> Alec
>
>
> On Wednesday, September 21, 2022 at 10:47:34 AM CDT, andy pugh <
> bodge...@gmail.com> wrote:
>
>
>
>
>
> On Wed, 21 Sept 2022 at 15:05, Chris Morley 
> wrote:
>
> > I think we should make the branch now. Making the branch does not
> preclude
> > doing finishing work in the branch.
>
>
> Indeed, it just makes "master" back into more of a testing playground.
>
>
> --
> 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
>
>
>
> --
>
> Message: 3
> Date: Thu, 22 Sep 2022 14:05:51 +0200
> From: J?r?mie Tarot 
> To: EMC developers 
> Subject: Re: [Emc-developers] Time to split 2.9 and master?
> Message-ID:
> <
> cach-gsghxezzqr+0qaotktv6qzqwfops+rselory0ckw98r...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Le mer. 21 sept. 2022 ? 04:24, Phill Carter  a
> ?crit :
> >
> > > On 21 Sep 2022, at 6:59 am, andy pugh  wrote:
> >
> > I have some plasmac work that I would like to push before that happens.
> It should be completed by the end of this month.
>
> As said in an earlier message, I believe [Qt]PlasmaC as well as the other
> UIs should have their own repositories and packages to unleash their
> development and release cycle. Of course the fact that PlasmaC embeds a HAL
> component together with configs for two UIs doesn't help... ?
>
> This could also be a good incentive for the projects to upgrade and
> standardize API and messaging between "core" and UIs.
>
> > I also have a question regarding packaging. Is there any good reason that
> we have a separate "-dev" package ?
>
> This is to have a finer grained packaging allowing to install and maintain
> just and only what's needed on each system. In the true spirit of *NIX,
> Debian and embedded/industrial systems design.
> There's still to be done on this matter until a PlasmaC integrator just
> have to `apt install plasmac` to install a slimmed and ready to configure
> controller, without any unneeded code, be it because it's only used by
> other UIs/VCPs or because it's only useful for developers.
>
>
> --
>
> Message: 4
> Date: Thu, 22 Sep 2022 14:07:09 +0200
> From: J?r?mie Tarot 
> To: EMC developers 
> Subject: Re: [Emc-developers] Time to split 2.9 and master?
> Message-ID:
>  n1pxtgko8k9pxgkdses9hm...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Le mar. 20 sept. 2022 ? 23:04, andy pugh  a ?crit :
>
> > Is it time to split 2.9 off as a stable-ish branch with a 2.9.0~pre0 tag?
>
>
> Would gladly hear the opinion of the "docs team" chaps about this :)
>
>
> --
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Emc-developers mailing list
> Emc-developer

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

[Alan Condit]

Chris,

Assuming that you have shown the include statement exactly as it is in the
file, you have a syntax error. The statement should be:

#include 

Alan

Date: Thu, 2 Jun 2022 08:13:04 -0400
> From: Curtis Dutton 
> To: EMC developers 
> Subject: Re: [Emc-developers] Trying to include asm/tsc.h
> Message-ID:
>  205anl3qsgnh-7bwte...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> #include
>

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

Re: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in Master

[Alan Condit]

Andy,

Has anyone familiar with Python looked at migrating to Py3 and GTK3?
I have avoided Python like the plague, but I do use a VCP and/or GTK based 
panels. 
I just looked at GTK3 and GTK4 is current, however, they say don’t migrate
 from GTK2 to GTK4 but rather from GTK2 to GTK3.

Alan

> Date: Tue, 11 May 2021 13:13:06 +0100
> From: andy pugh 
> To: EMC developers 
> Subject: [Emc-developers] Proposal: Stop supporting Py2 and GTK2 in
>   Master.
> This has been discussed a little in an out of the way corner of github:
> https://github.com/LinuxCNC/linuxcnc/pull/943#issuecomment-835870729
> 
> But I think that the time has come to decide that Py2 support does not
> belong in 2.9.
> I think that this also means losing GTK2 support(?), so there will be some
> breakage of UI and existing VCP panels.
> 
> There has been a suggestion to make a final Py2 release based on master,
> but I don't know if that would help all that much with those users running
> master from Buildbot, as they will probably still end up installing a
> Py2-free Master before they notice.
> 
> -- 
> 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

Re: [Emc-developers] chart of arrays

[Alan Condit]

>
>
>  Kirk,

 I think that one of the ways to re-ignite LinuxCNC is to pull some of the
changes that were done in Machinekit back into LinuxCNC. However, some
(maybe all) of those changes were done with no thought to release
versioning. That being said, those changes were important to some of the
former active development members. I don’t know if we could look at the
changes and possibly merge them into a “3.0” release.

Just a thought,
Alan

>

> From: Kirk Wallace wrote:
> It would be good to see LinuxCNC become more active again.
>
> Sincerely, Kirk Wallace


>

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

Re: [Emc-developers] Beagle Bone / PRU support ?

[Alan Condit]

Andy,

I have an extra BBB that is not in use. I would be happy to donate it to the 
project.

Alan

> Date: Sun, 28 Mar 2021 22:18:37 +0100
> From: andy pugh 
> To: EMC developers 
> Subject: Re: [Emc-developers] Beagle Bone / PRU support ?
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> On Sun, 28 Mar 2021 at 19:40, Jon Elson  wrote:
> 
>> I was wondering if there was any possibility that LinuxCNC
>> could support the Beagle Bone and Charles Steinkuehler's
>> driver for the PRU.
> 
> I have talked to Charles about it in the past (a few years ago) but
> wasn't really interested enough at the time to experiment.
> 
> It looks like the code will just drop into the LinuxCNC tree. But it
> only compiles on the Beaglebone. I don't have one set up here at the
> moment.
> 
> If you want to try compiling this new branch:
> https://github.com/LinuxCNC/linuxcnc/tree/andypugh/bb_pru
> 
> A problem is that with no BBB buildslave, no packages will be built by
> the buildbot.
> 
> --
> 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] Remove PDF Docs? (Was: DEB for linuxcnc HTML documentation)

[Alan Condit]

Andy,

I would prefer option 3 or 4. I like Gene prefer reading and searching in a pdf.

Alan

> Date: Mon, 21 Sep 2020 10:06:54 +0100
> From: andy pugh 
> To: EMC developers 
> Subject: [Emc-developers] Remove PDF Docs? (Was: DEB for linuxcnc HTML
>   documentation)
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> On Sun, 20 Sep 2020 at 20:10, Dr. Nikolaus Klepp  wrote:
>> 
>> I've made a deb with the HTML documentation of linuxcnc 2.8.0
> 
> I know that you were not suggesting that we remove the PDF docs, but I
> would like to expand the discussion in that direction.
> 
> The current tool chain can not build docs in non-latin alphabets. For
> 2.8 we had a fairly big submission of Chinese docs. These render OK in
> HTML: 
> http://linuxcnc.org/docs/2.8/html/getting-started/updating-linuxcnc-cn.html
> but attempting to build a PDF leads to a build failure.
> 
> A partial solution is to replace latex with xetex in the docs
> toolchain. However xetex is not available in Stretch.
> 
> A neater solution might be to use asciidoctor-pdf which is a one-step
> process from asciidoc to pdf. It seems to work well (and with Chinese)
> but relies on Ruby >v2.3 which is only the default version on the
> newer OS versions.
> 
> This is partly a buildbot issue. Do the docs that are distributed with
> the LinuxCNC version for a particular necessarily have to have been
> built with that OS?
> 
> Options:
> 1) Keep things as they are, don't attempt to distribute a Chinese docs 
> package.
> 2) Abandon PDF, distribute docs as HTML in the docs package.
> 3) Use xetex to make PDFs, abandon PDF docs build on older OS versions.
> 4) Use asciidoctor-pdf to make PDFs, abandon building PDF docs on
> older OS version
> 5) ...
> 
> 
> -- 
> 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

Re: [Emc-developers] upgrading python on raspbian

[Alan Condit]

Gene,

Read this link >. It gives great 
directions. Once I slowed down and followed them it all worked.

Alan

> 
> Message: 1
> Date: Sun, 13 Oct 2019 05:41:19 -0400
> From: Gene Heskett 
> To: python-l...@python.org, emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] upgrading python on raspbian
> Message-ID: <201910130541.19512.ghesk...@shentel.net>
> Content-Type: text/plain;  charset="utf-8"
> 
> I'm not a python expert by a long ways.
> 
> I have built the linuxcnc-master, which is the development branch of 
> linuxcnc, a machine control program to run most metal carving machines.
> Lathes, milling machines, anything you can motorize, LinuxCNC can run.
> 
> This requires a preempt-rt kernel which I've managed to build and 
> install, all on a pi-4b running raspbian buster, the armfh-v7l version 
> of debian 10.1.
> 
> But linuxcnc is quite elderly code, some of it going back to before there
> was a linux, so despite being actively developed right now for x86 type
> hardware but has quite a list of missing dependencies I cannot satisfy 
> from the raspbian repos.
> 
> They are:
> 
> The following packages have unmet dependencies:
> linuxcnc-uspace : Depends: python2.7-glade2 but it is not installable or
>python-glade2 but it is not going to be installed
>   Depends: python-gtksourceview2 but it is not going to be 
> installed
>   Depends: python-vte but it is not installable
>   Depends: python-gst0.10 but it is not installable
>   Depends: python-xlib but it is not going to be installed
>   Depends: python-gtkglext1 but it is not going to be 
> installed
>   Depends: python-configobj but it is not going to be 
> installed
>   Recommends: hostmot2-firmware-all but it is not installable
> 
> Can anyone supply a list of python3 packages that will cover the 
> functions contained in the above list?, and I will attempt to edit the 
> linuxcnc srcs to use the more modern code base?
> 
> Ignore the hostmot2-firmware-all package as its available, and may not 
> be actually required with the interface card in actual use. It has its 
> own fpga firmware already installed.
> 
> Thank you all.
> 
> 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)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page 
> 
> 
> 
> --


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

Re: [Emc-developers] LinuxCNC + RPi 4

[Alan Condit]

Gene,

The rpi4 is available in 1gb, 2gb and 4gb memory versions ($35, $45, $55 
respectively).

Alan

> Date: Sun, 21 Jul 2019 15:27:17 -0400
> From: Gene Heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] LinuxCNC + RPi 4
> Message-ID: <201907211527.17802.ghesk...@shentel.net>
> Content-Type: Text/Plain;  charset="utf-8"
> 
> On Sunday 21 July 2019 13:20:37 andy pugh wrote:
> 
>> On Thu, 18 Jul 2019 at 21:47, Pedro Grijalva  
> wrote:
>>> Hi I'Interested on run Linuxcnc on RP4
>>> can you share the steps ?
>> 
>> I have put the SD card image _temporarily_ here:
>> http://www.linuxcnc.org/dists/buster/2.8-uspace/
>> 
>> Note that this is a run-in-place setup, as the debian packaging isn't
>> set up quite right for Raspberry Pi.
>> This means that you need to type this at the command-line to run it.
>> (and yes, it really is dot space dot slash)
>> . ./linuxcnc-dev/scripts/rip-environment
>> linuxcnc
>> 
>> (or latency-test to run the latency test)
>> 
>> Please only download this if you have a Pi4 and genuinely want to
>> experiment, for the sake of the web site bandwith limits.
> 
> I am dl'ing it, and will get a pi4, and whatever card seems to be the 
> correct interface. Someone mentioned the 7i76E? but I've doubts it can 
> what I am doing.
> 
> To dup what I am doing with the 7i90HD and a stack of 7i42TA's, I'll need 
> 3 encoders, two stepgens, a pwm with direction for the vfd, two in's for 
> homes, and several outs. I don't think the 7i76D's I have can supply the 
> 2nd and 3rd encoders for the jog dials.
> 
> So what do I use?
> 
> A 7i90 with an ethernet connector might work, but what it has is rs422, 
> and likely too slow at 10 megabits. OTOH, if it can do spi at 50 
> megabits...  Actually I am writing at 42Mb and reading at 25Mb, and 
> thats working fairly well under stretch right now.
> 
> 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)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page 
> 



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

Re: [Emc-developers] Updates

[Alan Condit]

Gene,
If you can afford it and if it is actually available, you might want to upgrade 
to the $55 version of the pi4. It has 4gb of ram on it.
Alan

> Date: Mon, 1 Jul 2019 19:01:02 -0400
> From: Gene Heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] Updates
> Message-ID: <201907011901.02243.ghesk...@shentel.net>
> Content-Type: Text/Plain;  charset="utf-8"
> 
> On Monday 01 July 2019 14:10:46 Sebastian Kuzminsky wrote:
> 
>> On 7/1/19 11:55 AM, andy pugh wrote:
>>> On Mon, 1 Jul 2019 at 17:09, Sebastian Kuzminsky
>>> 
>>>  wrote:
> Also when I look at this page
> http://buildbot.linuxcnc.org/dists/stretch/
>  it shows master and
> 2.7 haven?t been updated since 09-Jun
 
 Oops!  Fixed, thanks for letting me know.
>>> 
>>> Any plans for a Buster Buildbot?
>> 
>> I'd very much like to add Buster builders to the Buildbot.
>> 
>> LinuxCNC builds on Buster and the tests pass, so run-in-place style
>> build-and-test should be doable today.
>> 
>> But some parts of LinuxCNC have runtime dependencies that are not
>> available in Buster.  We'd have to figure out what to do about those
>> parts before we can start shipping Buster debs...
>> 
> I had  a similar problem installing what I built on the pi running 
> realtime stretch when I went to install what I had built, following your 
> instructions that use dpkg-buildpackage. When I ran apt to install those 
> dependencies, I wound up with a downgrade of an already installed 
> package.  apt recommended a --fix-broken, which apparently completed the 
> removal of the updated package, then finished the install, and linuxcnc 
> is running normally now.
> 
> I found a realtime-buster and put it on a card about 1:30 ago, and it 
> booted to a text login but without finding either the keyboard or the 
> mouse, so that u-sd is in my pocket, waiting the RealtimePi to finish a 
> buster conversion, but I already know the video will still crawl as it 
> downgrading the buster 4.19.50 kernel to a 4.14.114, which I do not 
> think has the new video drivers in it kit.  We'll see in 2 or 3 hours 
> when thats done.  If it doesn't bail out early because the ssd went 
> read-only.  That faint knocking sound? Yup. :) Its probably warming up 
> the pi some too as I see by the build.log, that make was issued with 
> a -j4 argument.
> 
>>> Is it worth looking at cross-compiling for armhf if native arm
>>> boards are not reliable enough?
>>> (It's not particularly useful for build process testing, but having
>>> the debs would at least get some users testing)
>> 
> Like me. But I'm actually building on the pi, and I'm not hiding it, if 
> it works I have zero objections to shareing what works here.
> 
> I'm not doing much to a git clone except setting the ARCH=arm. For my 
> purposes I could probably strip it (the buster image) to half the size 
> it is now by making modules out of stuff I don't use here. I don't use 
> any sound and wifi is disabled too to keep the neighbors out. I don't 
> think they are doing it on purpose but they've used as much as 80G one 
> month before I disabled it in dd-wrt, and I can't bridge to anyplace but 
> my own net from the pi.  And I don't need to setup iptables on every 
> machine to keep the curious from snooping. 
> 
>> I'd much rather do native arm builds, both because of the test
>> coverage issue you mentioned and also to keep the build process
>> unified across hardware architectures.
> 
> Take care Seb.
> 
> Cheers, Gene Heskett



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

Re: [Emc-developers] using buildbot on the pi

[Alan Condit]

Charles,

Do you know what would be involved to build linuxcnc rather than machinekit 
using the mk-cross-builder?

Would we have to set up a separate account?
Would we have to create linuxcnc-cross-builder from mk-cross-builder?
I was never able to get Docker 15 to run on my machine, would the cross-builder 
run on Docker 17?

Thanks,
Alan

> Date: Wed, 15 May 2019 11:24:29 -0500
> From: Charles Steinkuehler 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] using buildbot on the pi
> Message-ID: <40633b4e-8088-63cd-3870-bcf83138c...@steinkuehler.net>
> Content-Type: text/plain; charset=utf-8
> 
> FYI: The docker build containers John Morris put together should work
> well to build LinuxCNC for ARM, and an armhf cross-build takes less
> than 15 minutes from scratch (no cache):
> 
> https://hub.docker.com/r/dovetailautomata/mk-cross-builder/
> 
> ...using VMs is IMHO a lot more convenient than trying to keep a
> reasonably powered ARM system up and running.  :)
> 
> Example Travis CI integration scripts can be pulled from the various
> Machinekit repos on github.
> 
> On 5/15/2019 10:25 AM, Alan Condit wrote:
>> Gene,
>> 
>> I would suggest putting an SSD on one of your Rock64 boards USB3 port. It 
>> will build at least 4 to 6 times faster than the USB2 port on the Rpi 3b+. 
>> Just install stretch or what ever your are using on the pi on the Rock64 and 
>> build away. You can build the debs and then you should be able to install 
>> the debs on the pi.
>> 
>> Alan
>> 
>>> Date: Tue, 14 May 2019 10:58:03 -0400
>>> From: Gene Heskett 
>>> To: emc-developers@lists.sourceforge.net
>>> Subject: [Emc-developers] using buildbot on the pi
>>> Message-ID: <201905141058.03322.ghesk...@shentel.net>
>>> Content-Type: text/plain;  charset="utf-8"
>>> 
>>> Greetings all;
>>> 
>>> Can the buildbot be rigged to run on a pi with an SSD on the usb bus for 
>>> its working storage?  If it can, I might like to see the recipes used to 
>>> make it on your armhf odroid? I have a 60GB SSD on the pi. And I have 
>>> built kernels on it. Slow, as in hours, but acts like it worked, no 
>>> bailouts, so I might as well try to build linuxcnc on it too.
>>> 
>>> 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 <http://geneslinuxbox.net:6309/gene>
>> 
>> 
>> 
>> ___
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>> 
> 
> 
> -- 
> Charles Steinkuehler
> char...@steinkuehler.net



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

Re: [Emc-developers] using buildbot on the pi

[Alan Condit]

> Date: Wed, 15 May 2019 21:21:27 -0400
> From: Gene Heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] using buildbot on the pi
> Message-ID: <201905152121.27400.ghesk...@shentel.net>
> Content-Type: Text/Plain;  charset="iso-8859-1"
> 
> On Wednesday 15 May 2019 11:25:50 am Alan Condit wrote:
> 
>> Gene,
>> 
>> I would suggest putting an SSD on one of your Rock64 boards USB3 port.
>> It will build at least 4 to 6 times faster than the USB2 port on the
>> Rpi 3b+. Just install stretch or what ever your are using on the pi on
>> the Rock64 and build away. You can build the debs and then you should
>> be able to install the debs on the pi.
>> 
>> Alan
> However, how do I build for armhf on an arm64?

I don’t know. I switched to arm64 and build for it. 

I was worried about the latency until I talked to Peter Wallace. Since the 
latency mainly runs about 3-13 us occasional bumps to 50us shouldn’t hurt a 100 
us thread (because, as I understand it, Peter has implemented a PLL to keep 
things in sync). However, don’t listen to me, talk to Peter or maybe Peter will 
chime in a clarify for all of us.

I bought a 7i76e to run off the RockPro64’s gigabit ethernet (doesn’t run off 
the USB). I don’t know how tight the timing is on your SPI stuff.

> Got question on Rock64 since they came with almost zero docs, I note 
> there are 3 std sized usb ports, two have white plastic inserts, while 
> the single stack port adjacent to the pair has a robins egg blue plastic 
> insert.  Does this means it is the usb-3 port?
> 

Yes.

> 
> Thanks Alan.  And networking has failed AGAIN. I'll go try a full 
> powerdown for 30 seconds. The armbian stretch is so ticklish that if the 
> network cable isn't plugged in when ts booted, it will never find it no 
> matter how many times you hit the reset/restart button.
> 
> Can you show me a WORKING /e/n/i.d/eth0 file for static network that 
> actually works? From a hot reboot or /etc/init.d networking restart?

Not a clue. I haven’t had that problem on stretch.

> 
> I can't query for the failure because that man page for ip might as well 
> be written in swahili. Not an example in a trainload of copies of that 
> worthless pile of gibberish pretending to be English.
> 
> Anyway, networking is networked.  Its been a while since it was updated, 
> so lets see if it will.
> 
> Its been in a box for at least 3 weeks, but:
> sudo apt update:
> Reading package lists... Done
> E: The repository 'http://apt.armbian.com stretch Release' does no longer 
> have a Release file.

If you insist on staying 32bit, look in here:
https://apt.armbian.com/dists/stretch/main/binary-armhf/ 
<https://apt.armbian.com/dists/stretch/main/binary-armhf/>

Try using (just a WAG you may have to play with it):
https://apt.armbian.com/dists/ <https://apt.armbian.com/dists/> stretch Release

> N: Updating from such a repository can't be done securely, and is 
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user 
> configuration details.
> 
> So armbian stretch (from http://cdn-fastly.deb.debian.org/debian 
> stretch-updates/main armhf Packages) is out of date and can no longer be 
> updated: My thoughts aren't printable. When did that happen?
> 
> I may as well upgrade to beta, something I've never done before to an 
> existing system, so how is this done?
> 
> Thanks Alan.
> 
> 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 <http://geneslinuxbox.net:6309/gene>


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

Re: [Emc-developers] using buildbot on the pi

[Alan Condit]

Gene,

I would suggest putting an SSD on one of your Rock64 boards USB3 port. It will 
build at least 4 to 6 times faster than the USB2 port on the Rpi 3b+. Just 
install stretch or what ever your are using on the pi on the Rock64 and build 
away. You can build the debs and then you should be able to install the debs on 
the pi.

Alan

> Date: Tue, 14 May 2019 10:58:03 -0400
> From: Gene Heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: [Emc-developers] using buildbot on the pi
> Message-ID: <201905141058.03322.ghesk...@shentel.net>
> Content-Type: text/plain;  charset="utf-8"
> 
> Greetings all;
> 
> Can the buildbot be rigged to run on a pi with an SSD on the usb bus for 
> its working storage?  If it can, I might like to see the recipes used to 
> make it on your armhf odroid? I have a 60GB SSD on the pi. And I have 
> built kernels on it. Slow, as in hours, but acts like it worked, no 
> bailouts, so I might as well try to build linuxcnc on it too.
> 
> 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

Re: [Emc-developers] buildbot for arm64

[Alan Condit]

Gene,

I got my SSD and hooked it up to the USB3 port. I tried to follow the 
directions in “Building LinuxCNC”.
 After a bunch of time figuring out what I was missing in required 
dependencies, it took about 10 minutes to build linuxcnc-uspace 
(linuxcnc-uspace_2.8.0~pre1_arm64.deb) and it took a total of twenty-five 
minutes to figure out the dependencies required to install and install the debs.

Yea!!!
Alan

> Date: Sun, 28 Apr 2019 03:03:38 -0400
> From: Gene Heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] buildbot for arm64
> Message-ID: <201904280303.38300.ghesk...@shentel.net>
> Content-Type: Text/Plain;  charset="utf-8"
> 
> On Saturday 27 April 2019 23:49:39 Alan Condit wrote:
> 
>> Gene,
>> 
>> I built the kernel on the uSD.
>> 
>> I have a 32gb SSD that doesn?t seem to want to work.
> 
> Likely used up, some have a pretty poor write life.
> 
>> So I ordered a 
>> 240gb SSD and a SATA to USB3.0 case from Walmart. I started to order a
>> 120gb SSD but the shipping was almost as much as the difference in
>> price between the smaller one and the larger one and I got free
>> shipping with the larger one and case.
>> 
>> I have an 80gb 2.5? HD (usb2.0) that I tried flashing like a uSD. It
>> wouldn?t boot but I was able to mount it and access the files. I guess
>> I?ll just have to wait till my SSD arrives.
> 
> I've had pretty poor luck with the 2.5" spinning rust drives. The rock64 
> killed a wallmart 1Tb 2.5" usb3 drive with the first kernel build. 
> Something is wrong with the rock64's usb3 socket according to the kernel 
> experts, but it still works ok with usb2 stuff, and thats what I was 
> useing when I built a kernel in an hour.
> 
>> I bought the 16gb EMMC also, but I also bought the usb to EMMC
>> programmer. I just flashed the EMMC with Etcher. I will reflash it,
>> when I am satisfied that I have the OS and linuxcnc working. The usb
>> programmer has the same kind of socket on it that the board has, so
>> you just mount the EMMC on the programmer and flash it like a uSD,
>> then take it off the programmer and mount it on the board. When it is
>> mounted on the board the board will boot from it instead of the uSD.
>> 
> I didn't see that, or I would have bought it. Inferred from the 
> propaganda was that the rock64 could do that by itself.  But if a dd 
> like program could do it, it seems to me dmesg ought to ident the eMMC 
> so dd would have a of=/dev/target.  But it doesn't seem to recognize it.  
> Does yours before its been programmed?
>> 
>>> Date: Sat, 27 Apr 2019 11:54:19 -0400
>>> From: Gene Heskett 
>>> To: emc-developers@lists.sourceforge.net
>>> Subject: Re: [Emc-developers] buildbot for arm64
>>> Message-ID: <201904271154.19577.ghesk...@shentel.net>
>>> Content-Type: Text/Plain;  charset="iso-8859-1"
>>> 
>>> On Saturday 27 April 2019 11:08:20 Alan Condit wrote:
>>>> I have just completed building 4.19.31 LTS preempt_rt for my
>>>> RockPro64 (on my RockPro64). I would love to have access to
>>>> linuxcnc builds from a buildbot for arm. 
> 
> The Odroid's that they were using to build the armhf for me, were a huge 
> crashing headache for John K. so he took them back out of the buildbot 
> farm in Sept 2018.  So if I want a new LCNC for my pi, I'm going to have 
> to git clone master and build it myself. I don't relish the thought, 
> with no more memory than the pi has, it will be a make -j2 at the most 
> and several hours, and I expect before I do that, I'd better invest in a 
> 128 Gb u-sd, clone that 32 its running on now to it with dd, and let 
> resize2fs adjust it to use the whole card.
> 
> Theres supposed to be a one time fuse in the pi which will make it boot 
> from a usb2 drive, but I have run that command to blow that fuse 10 or 
> more times w/o its working, so its still stuck booting from the u-sd.
> I think my pi's are too early.  And I'm still trying to decide if the pi4 
> was an April 1 release, and if its real, is it back compatible?  It will 
> take more research, probably with the bull shit filter turned way up.
> 
>>>> It took about 8 hours to 
>>>> compile the kernel, so I am not looking forward to building
>>>> linuxcnc on my RockPro64. I could load machinekit but they seem to
>>>> never have a stable release and almost no documentation.
> 
> So I've noted...
> 
> Take care Alan
> 
> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defens

Re: [Emc-developers] buildbot for arm64

[Alan Condit]

Gene,

I built the kernel on the uSD.

I have a 32gb SSD that doesn’t seem to want to work. So I ordered a 240gb SSD 
and a SATA to USB3.0 case from Walmart. I started to order a 120gb SSD but the 
shipping was almost as much as the difference in price between the smaller one 
and the larger one and I got free shipping with the larger one and case.

I have an 80gb 2.5” HD (usb2.0) that I tried flashing like a uSD. It wouldn’t 
boot but I was able to mount it and access the files. I guess I’ll just have to 
wait till my SSD arrives.

I bought the 16gb EMMC also, but I also bought the usb to EMMC programmer. I 
just flashed the EMMC with Etcher. I will reflash it, when I am satisfied that 
I have the OS and linuxcnc working. The usb programmer has the same kind of 
socket on it that the board has, so you just mount the EMMC on the programmer 
and flash it like a uSD, then take it off the programmer and mount it on the 
board. When it is mounted on the board the board will boot from it instead of 
the uSD.

Alan

> Date: Sat, 27 Apr 2019 11:54:19 -0400
> From: Gene Heskett 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] buildbot for arm64
> Message-ID: <201904271154.19577.ghesk...@shentel.net>
> Content-Type: Text/Plain;  charset="iso-8859-1"
> 
> On Saturday 27 April 2019 11:08:20 Alan Condit wrote:
> 
>> I have just completed building 4.19.31 LTS preempt_rt for my RockPro64
>> (on my RockPro64). I would love to have access to linuxcnc builds from
>> a buildbot for arm. It took about 8 hours to compile the kernel, so I
>> am not looking forward to building linuxcnc on my RockPro64. I could
>> load machinekit but they seem to never have a stable release and
>> almost no documentation.
>> 
>> Alan
>> 
> Alan, how are your building it, as in to what storage medium?  I could 
> believe that 8 hours to an u-sd card, but one compile will likely use up 
> the life of the cards wear leveling unless its way bigger than 32GB. Get 
> a 10 dollar usb to sata cable from those folks, and stick a 40 to 120 GB 
> SSD on it.  Running that way, its an hour or less on one of my rock64's 
> w/4GB of ram. And a 16Gb eMMC I haven't figured out how to use yet. Docs 
> from the pine folks aren't at all descriptive to an English speaker 
> who's never seen a rock64 before.
> 
> 
> Cheers, Gene Heskett



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

[Emc-developers] buildbot for arm64

[Alan Condit]

I have just completed building 4.19.31 LTS preempt_rt for my RockPro64 (on my 
RockPro64). I would love to have access to linuxcnc builds from a buildbot for 
arm. It took about 8 hours to compile the kernel, so I am not looking forward 
to building linuxcnc on my RockPro64. I could load machinekit but they seem to 
never have a stable release and almost no documentation.

Alan

> 
> Message: 1
> Date: Fri, 26 Apr 2019 23:11:39 -0400
> From: Gene Heskett 
> To: EMC developers 
> Subject: [Emc-developers] buildbot fpr armhf?
> Message-ID: <201904262311.40020.ghesk...@shentel.net>
> Content-Type: text/plain;  charset="utf-8"
> 
> Greetings all;
> 
> I am wondering what has happened to the buildbot that was generating new 
> images of master for my pi.  My last linuxcnc update was in the middle 
> of Sept 2018.  Its beginning to feel neglected. ;-)
> 
> 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

Re: [Emc-developers] future of rpi?

[Alan Condit]

Gene,

Here is an unofficial site 
<http://unofficialpi.org/Distros/RealtimePi/nightly/> for raspberry pi systems.
Take a look at:
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-11-06_2018-10-09-realtimepi-stretch-lite-0.4.0.zip
 
<http://unofficialpi.org/Distros/RealtimePi/nightly/2018-11-06_2018-10-09-realtimepi-stretch-lite-0.4.0.zip>
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-11-06_realtimepi-kernel-4.14.74.tar.gz
 
<http://unofficialpi.org/Distros/RealtimePi/nightly/2018-11-06_realtimepi-kernel-4.14.74.tar.gz>
http://unofficialpi.org/Distros/RealtimePi/nightly/2018-11-06_2018-10-09-realtimepi-stretch-lite-0.4.0.zip.md5
 
<http://unofficialpi.org/Distros/RealtimePi/nightly/2018-11-06_2018-10-09-realtimepi-stretch-lite-0.4.0.zip.md5>

I believe this stuff is all 32bit.

Yeah, the Pine64 group is much smaller than the raspberry pi group. I bought a 
Pine64 A64+ during the kickstarter campaign. I have it running a vanilla kernel 
and I have never succeeded in getting the LCD screen that I bought with it 
working. One of the guys over at machinekit got it working on a pine64. 
Personally, I wish I had waited, I really like the features of the RockPro64 
(4gb ram, USB3.0, and gigabit ethernet. I may buy one of them to play with and 
see if I can get preempt-rt working. For me I hate the fact that the ethernet 
runs on the USB bus.

Do you have a picture of how you connected the rpi3b SPI to the 7i90HD?

Alan

> On Mar 9, 2019, at 12:30 PM, Gene Heskett  wrote:
> 
> On Saturday 09 March 2019 13:36:24 Alan Condit wrote:
> 
>> Gene,
>> 
>> Do you have a 2nd rpi 3b? If so you could build a stretch 64 bit
>> system for it without impacting your Sheldon. That way you could at
>> least test that it was booting and running before even trying to load
>> linuxcnc on it.
>> 
>> You talked at one time about a Rock64 or RockPro64. The RockPro64 has
>> 4gb of memory and gigabit ethernet (so my guess is that its ethernet
>> doesn’t run on the usb bus. However, it is more expensive.
>> 
>> Alan
> 
> I have a pair of rock64's with 4 gigs of ram, $44 a copy. But its all run 
> by proprietary schooled people with zero interest in millisecond real 
> time.  Installed stretch, ran nice but it took a couple months to get 
> the magic incantation so route would actually work, no net until then.  
> I assume thats  been fixed by now but...
> 
>> 
>>> On Mar 9, 2019, at 10:15 AM, Gene Heskett 
>>> wrote:
>>> 
>>> On Saturday 09 March 2019 11:34:55 you wrote:
>>>> Gene,
>>>> I just learned this the other day. Try uname -m. It should show the
>>>> architecture that it is running on.
>>>> I have a D525MW that I usually use to cross compile for ARM.
>>>> Alan
>>> 
>>> I get armv71
>>> 
>>>> On Sat, Mar 9, 2019, 12:35 AM Gene Heskett 
>>> 
>>> wrote:
>>>>> On Friday 08 March 2019 23:21:28 you wrote:
>>>>>> Gene,
>>>>>> 
>>>>>> I know the rpi 3b+ is a 64 bit processor, but I understand that
>>>>>> it also runs the 32bit software. So, my question is this, are you
>>>>>> running 32bit OS or 64bit?
>>>>>> 
>>>>>> I am looking at various preempt rt kernels for the rpi. Some
>>>>>> kernels are up as far as 4.14.74 preempt rt for the 32bit mode.
>>>>>> The latest kernel that I have found that sounds somewhat stable
>>>>>> specifically for the rpi 3b(+)
>>>>>> linux-image-4.19.8-rt6-v8_4.19.8-rt6-v8-1_arm64.deb.
>>>>>> 
>>>>>> So, are you looking for source to compile or an image to install?
>>>>>> Are you willing to move to Stretch or do you want to stick with
>>>>>> Jessie?
>>>>>> 
>>>>>> Here is an article with directions for building Real-Time Linux
>>>>>> on the Raspberry Pi
>>>>>> <https://www.get-edi.io/Real-Time-Linux-on-the-Raspberry-Pi/> a
>>>>>> Preempt_RT patched linux kernel for 64 bit rpi 3b+.
>>>>> 
>>>>> This doesn't work on wheezy failing 3 links in at step one of
>>>>> creating a container because its apt-get yet on wheezy.  And it
>>>>> doesn't work on the pi's jessie install, no snapd for jessie.
>>>>> 
>>>>> So I don't have an install even capable of doing it your way here.
>>>>> 
>>>>> The box I'm using to run mesaflash might be able to run stretch,
>>>>> but I'll need to in

Re: [Emc-developers] future of rpi?

[Alan Condit]

Gene,
I just learned this the other day. Try uname -m. It should show the
architecture that it is running on.
I have a D525MW that I usually use to cross compile for ARM.
Alan


On Sat, Mar 9, 2019, 12:35 AM Gene Heskett  wrote:

> On Friday 08 March 2019 23:21:28 you wrote:
>
> > Gene,
> >
> > I know the rpi 3b+ is a 64 bit processor, but I understand that it
> > also runs the 32bit software. So, my question is this, are you running
> > 32bit OS or 64bit?
> >
> > I am looking at various preempt rt kernels for the rpi. Some kernels
> > are up as far as 4.14.74 preempt rt for the 32bit mode. The latest
> > kernel that I have found that sounds somewhat stable specifically for
> > the rpi 3b(+) linux-image-4.19.8-rt6-v8_4.19.8-rt6-v8-1_arm64.deb.
> >
> > So, are you looking for source to compile or an image to install? Are
> > you willing to move to Stretch or do you want to stick with Jessie?
> >
> > Here is an article with directions for building Real-Time Linux on the
> > Raspberry Pi
> >  a
> > Preempt_RT patched linux kernel for 64 bit rpi 3b+.
> >
> This doesn't work on wheezy failing 3 links in at step one of creating a
> container because its apt-get yet on wheezy.  And it doesn't work on the
> pi's jessie install, no snapd for jessie.
>
> So I don't have an install even capable of doing it your way here.
>
> The box I'm using to run mesaflash might be able to run stretch, but I'll
> need to install to a fresh ssd as the drive in it has all my mesa files
> I'd druther not lose my mesa collection.  Or maybe even try buster which
> is in late alpha. I may as well start learning its foibles.  Whats the
> best way to get a latest buster iso.  Got the jigdo files for alpha5
> coming in now.
>
> But that can't be made to work, no files from the template can be
> found. ???  So konqueror is pulling the whole first .iso. But damn that
> site is slow, 36 hours to get it all. For one dvd...
>
> And from the build dates, I've heard rumors the D-I is busted. I guess
> I'll find out.  Might be a waste of time. I could even fall over by
> then. But the pacemaker will try to keep me going.
>
> Back to bed, while konqueror shuffles slowly along at 32kb/sec.
>
> > Alan
>
>
> 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

Re: [Emc-developers] future of rpi?

[Alan Condit]

Gene,

I know the rpi 3b+ is a 64 bit processor, but I understand that it also runs 
the 32bit software. So, my question is this, are you running 32bit OS or 64bit?

I am looking at various preempt rt kernels for the rpi. Some kernels are up as 
far as 4.14.74 preempt rt for the 32bit mode. The latest kernel that I have 
found that sounds somewhat stable specifically for the rpi 3b(+) 
linux-image-4.19.8-rt6-v8_4.19.8-rt6-v8-1_arm64.deb.

So, are you looking for source to compile or an image to install? Are you 
willing to move to Stretch or do you want to stick with Jessie?

Here is an article with directions for building Real-Time Linux on the 
Raspberry Pi  a 
Preempt_RT patched linux kernel for 64 bit rpi 3b+.

Alan


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

Re: [Emc-developers] Arm with PCIe -- mesa 6i25 (Peter C. Wallace)

[Alan Condit]

I am not a big fan of IBM but I have to say that because they defined the PC 
bios and interrupt structure,
we all owe them a debt of gratitude for the continued degree of compatibility 
on the X86 machines.

I thought that there was already a stable rt-preempt kernel for 4.9 LTS and 
4.14 LTS and they were approaching stable on the 4.19 LTS rt-preempt kernel. 
However, I now realize that I was looking at the GitHub for rt-preempt generic.
It looks like there maybe something approaching stable for 4.9 LTS for Pine64. 
I am not sure of the relationship between the Pine64 and RockPro64. Pine64+ 
uses an Allwinner cpu, while the RockPro64 uses RK3399 which is Armv8.

I have built kernels in the past but am not an expert.

Alan

> Message: 4
> Date: Fri, 8 Mar 2019 08:56:46 -0800 (PST)
> From: "Peter C. Wallace" 
> To: EMC developers 
> Subject: Re: [Emc-developers] Arm with PCIe -- mesa 6i25
> Message-ID: 
> Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
> 
> On Fri, 8 Mar 2019, Alan Condit wrote:
> 
>> Date: Fri, 8 Mar 2019 08:34:39 -0800
>> From: Alan Condit 
>> Reply-To: EMC developers 
>> To: emc-developers 
>> Subject: [Emc-developers] Arm with PCIe -- mesa 6i25
>> 
>> I am looking at processors for my next controller. I saw yesterday that the 
>> RockPro64 has a PCIe 4x connector. It has a six core RK3399 - dual core A72 
>> - quad core Arm53. At the moment that doesn??t mean much to me.
> 
>> Anyway my question is would it be feasible to use the RockPro64 with a 6i25
>> board and if, yes, what would be required to use a 6i25 with that processor, 
>> i.e., is it just recompiling some ??C?? code or is there a bunch of assembly 
>> code that would have to be rewritten.
>> 
>> Thanks,
>> Alan
> 
> 
> I suspect any changes (if needed) would be pretty minor, but a bigger 
> question 
> is can you get or build a reliable real time kernel for the RockPro. One 
> issue 
> with the ARM boards is that each one is different enough that its often an 
> 'adventure' to do things that are trivial on x86 because of per ARM board 
> idiosyncrasies.
> 
> Peter Wallace
> Mesa Electronics



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

[Emc-developers] Arm with PCIe -- mesa 6i25

[Alan Condit]

I am looking at processors for my next controller. I saw yesterday that the 
RockPro64 has a PCIe 4x connector. It has a six core RK3399 - dual core A72 - 
quad core Arm53. At the moment that doesn’t mean much to me. 

Anyway my question is would it be feasible to use the RockPro64 with a 6i25 
board and if, yes, what would be required to use a 6i25 with that processor, 
i.e., is it just recompiling some ‘C’ code or is there a bunch of assembly code 
that would have to be rewritten.

Thanks,
Alan

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

Re: [Emc-developers] Emc-developers Digest, Vol 155, Issue 12

[Alan Condit]

Hey Peter,

What is RMU? The only thing I found was Robert Morris University.

Thanks,
Alan

>   4. Re: future of rpi? (Peter C. Wallace)
> Message: 4
> Date: Wed, 6 Mar 2019 10:44:32 -0800 (PST)
> From: "Peter C. Wallace" 
> To: EMC developers 
> Subject: Re: [Emc-developers] future of rpi?
> Message-ID: 
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> I've had a RPI running LinuxCNC master here (with 7C80 hardware)
> for about 8 months 24/7 and I have not seen any network (I'm using WIFI) or 
> KB/Mouse issues, but I have (deliberatly) not done any updates.
> This is running stretch:
> 
> PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
> NAME="Raspbian GNU/Linux"
> VERSION_ID="9"
> VERSION="9 (stretch)"
> ID=raspbian
> ID_LIKE=debian
> HOME_URL="http://www.raspbian.org/";
> SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
> BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";
> 
> Using a kernel I got from RMU (thanks RMU!):
> 
> Linux raspberrypi 4.9.65-rt56-v7+ #3 SMP PREEMPT RT Thu Dec 14 12:26:15 CET 
> 2017 armv7l GNU/Linux
> 
> You do have to enable hardware OpenGL or the backplot is painfully slow and 
> you cannot manipulate full screen dense backplots without running out of the 
> RPIs meager memory space. ( This may be fixed eventually by the very clever 
> guys working on QtPyVCP that have reduced the backplot memory footprint and 
> speed it up considerably using VTK )
> 
> I can post the config.txt and cmdline.txt files if you like
> 
> Peter Wallace
> Mesa Electronics



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

Re: [Emc-developers] future of rpi? (Gene Heskett)

[Alan Condit]

Gee Gene,

I hope you don’t give up on the rpi just yet. I am just getting interested
in trying something, although I was thinking of a rpi3b+ with 7i76e.

Alan

>   2. future of rpi? (Gene Heskett)
> Message: 2
> Date: Tue, 5 Mar 2019 20:50:23 -0500
> From: Gene Heskett 
> To: EMC developers 
> Subject: [Emc-developers] future of rpi?
> Message-ID: <201903052050.23277.ghesk...@shentel.net>
> Content-Type: text/plain;  charset="utf-8"
> 
> Greetings all;
> 
> About 90 days back there were some new kernels and libraries made 
> available that I've heard sped up the video on the pi's quite a bit.
> 
> But I have the stuff wrapped around the realtime kernel its running 
> pinned so as not to lose the ability to run my lathe.  That file is 
> here:
> pi@picnc:/etc/apt/preferences.d $ cat kernel.pref
> Package:linux-kernel
> pin: version 4.4.4-rt9-v7+
> Pin-Priority: 1001
> 
> Package: linux-headers
> Pin: version 4.4.4-rt9-v7+
> Pin-Priority: 1001
> 
> Package: raspberrypi-bootloader
> Pin: version 1.20170427-1
> Pin-Priority: 1001
> 
> Package: raspberrypi-kernel
> Pin: version 1.20170427-1
> Pin-Priority: 1001
> 
> But while they been pinned, apparently the video has been updated and the 
> older signal paths between the keyboard/mouse, and feedback to the video 
> have been destroyed to the extent that my sheldon is now no longer 
> usable. There is now at least a 1 second delay for any keyboard or mouse 
> event to get to linuxcnc from my fingers, and at least a 1 second delay 
> between lcnc's movements of the machine, and any update making it back 
> to the backplot. An because the machine isn't under the usual tight 
> control I've now destroyed 2 of the very expensive, smallest 3 cornered 
> threading chips for making external threads.
> 
> So I need a freshly built and installable realtime kernel that is 
> compatible with the latest libraspberripi.bin and friends, or I'm going 
> to have to find a D-525-MW mobo and reconvert it to a 7i90 with a 
> parport interface since theres no such thing as an spi driver for the 
> x86 boards. Given the rpi communities attitude vis-a-vis machine 
> controls, (we are being ignored on their many lists and forums, the rare 
> exception being the linux-arm list) it looks like going back to an intel 
> driven system is the only choice I really have if I want a useable lathe 
> again. My biggest problem is where the heck am I going to put a D-525-MW 
> mobo in the hacked up mess hanging on the riser pole on the back of the 
> machine now.
> 
> I have several later rt kernels built, right there on the pi, but so far, 
> despite repeated pleas for instructions on how to install them, nothing 
> has been offered, and I'm now convinced after 2 years, that the pi folks 
> would just as soon I took the blue pill and went away. I wish there were 
> a thousand of me beating on the drums for support, but one voice is 
> swept away in the multimedia wind.
> 
> So is there a chance of a new kernel, realtime enough to work with 
> linuxcnc AND take advantage of the new video modes made available in the 
> last 5 or 6 months which might materialize by the 1st of May, or do I 
> put a intel mobo on it and install from the wheezy install iso?  Does 
> that involve the wholesale replacement of $200+ worth of 7i90HD+ 3x 
> 7i42TA's with something else?  That, once the noise was whupped, has 
> Just Worked. I think the question then is, is the intel parport fast 
> enough to service the 7i90HD over that interface?
> 
> I know that manpower to support one user of this architecture is not 
> efficient use of your time so if I have to rebuild, I won't be hugely 
> upset as this is the real world, but while it worked, it worked quite 
> well.
> 
> So what say you folks?
> 
> Like Douglas Adams, Thanks for the fish.
> 
> 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

Re: [Emc-developers] Things you can't do with radius compensation on.

[Alan Condit]

Andy,

With regards to M6 it seems that changing tool size might be just like starting 
out with cutter comp, it needs some ramp in distance to establish the cutter 
compensation distance and it wouldn’t know how much to apply. 

Alan

> Date: Tue, 2 Oct 2018 12:16:54 +0100
> From: andy pugh 
> To: EMC developers 
> Subject: [Emc-developers] Things you can't do with radius compensation
>   on.
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> https://github.com/LinuxCNC/linuxcnc/blob/b948dba1af9e63f26498cf005d6693cec30458a9/src/emc/rs274ngc/interp_convert.cc#L3302
> 
> There seem to be a lot of things that are not allowed with cutter comp
> enabled, and it isn't immediately obvious why.
> 
> The following G-codes are banned
> 
> G61 - Seems reasonable
> G54, G55...G59.3 - OK
> M62 ... M68  Analog-digital IO -- This seems odd
> M48 - M53 - Spindle and feed overrides -- This also seems unreasonable
> G98 - G99 -- Cycle retract mode -- Again this seems an odd thing to disallow
> G76 lathe threading -- It seems like you might very much want to use
> cutter comp here?
> M6 tool change -- Why wouldn't cutter-comp just carry through with the
> new radius?
> G43 - G49 -- Might be reasnable, but doesn't seem necessary.
> 
> -- 
> 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

Re: [Emc-developers] Emc-developers Digest, Vol 149, Issue 4

[Alan Condit]

Chris,

This might be a good time to start looking at Linuxcnc 3.0? Major differences 
deserve time to make them happen right.

Alan

> Date: Sat, 8 Sep 2018 19:05:48 +
> From: Chris Morley 
> To: EMC DEV 
> Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
> Message-ID:
>   
> 
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I see that machinekit has broken out HAL and cnc (Well and lots of others) 
> into different repositories.
> 
> https://github.com/machinekit
> 
> [https://avatars1.githubusercontent.com/u/6759549?s=280&v=4]
> 
> machinekit ? GitHub
> github.com
> GitHub is where people build software. More than 28 million people use GitHub 
> to discover, fork, and contribute to over 85 million projects.
> 
> It also seems they have updated HAL considerably,
> 
> They were working on RT multicore support, anytime instantiation of HAL 
> components
> 
> cython support.. probably other stuff - I'm not sure if it includes ARM or 
> FPGA upgrades.
> 
> 
> I was thinking that maybe linuxcnc should discuss if that is something that 
> would be of interested.
> 
> 
> pros I see:
> 
> -chance to break HAL out of cnc stack
> 
> -seemingly an upgrade in capability
> 
> -someone else has done a lot of work/testing already
> 
> -might allow more cross work of developers between the projects
> 
> 
> cons:
> 
> -surely a lot of work to incorporate (though it does support legacy code, if 
> I understand right)
> 
> -lack of experience with concepts/code - will take time to become comfortable
> 
> -we'd have to admit they are not bad people :)
> 
> 
> Ok that last one was meant as fun.
> 
> 
> There are very smart and hard working people on both projects, it would be 
> nice to benefit both
> 
> projects.
> 
> 
> I have not really looked at the code, nor am qualified to give indepth 
> opinion of the code.
> 
> I have watched the video of the multicore idea.
> 
> https://www.youtube.com/watch?v=brT0bEkJLSY
> 
> There are more videos (including one about the trajectory planner that we now 
> use)
> 
> 
> Thoughts?
> 
> 
> Chris M
> 



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

[Emc-developers] Proposal: Branch stepconf to create a new more advanced configuration wizard.

[Alan Condit]

I propose that we branch stepconf and create a new advancedconf  
wizard to ultimately be included in EMC2 releases alongside stepconf.

Ability to import stepconf and save advance conf

The new wizard might eventually support things such as:
Tabs for configurations using:
 Step/Dir
 PWM
 Analog 0-10 vdc
Tabs to help implement:
 Pendant/MPG/Joystick
 Spindle Encoder
 Backlash Comp
 Draw Pyvcp panels supporting all existing widgets and
 Create MDI Commands
 (Maybe Classic Ladder at some point)
 and to the point that it is designed to be user customizable  
(support for Axis customization)

Support for Configuration of stepper and servo systems using:
 Mesa HostMot2 - 5I20 & 7I43
 PicoSystems - ???

Support for conversions to EMC2 using various existing machines, BOBs  
and drives:
 Machines:
 Sherline
 Industrial Hobbies
 Tormach
 Smithy
 Seig, etc
 Drives:
 Geckodrive G540
 Xylotex
 Geckodrives
 The new mini-cpld drives, etc
 BOBs
 CandCNC
 Campbell (SoundLogic)
 CNC4PC, etc

Servo tuning as well as stepper testing
Scale verification facility (check requested motion relative to  
achieved motion) and scale adjustment.

Possibly the ability to output a wiring list that would allow someone  
to create a config
and then wire a controller to match.

Also a procedure by which a implementor or manufacturer could provide
the necessary information in a required format and have a new drive,  
BOB or
machine to the configuration wizard.

I would also suggest that we create an actual plan for development  
(goals and priorities)

Thanks,
Alan

---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

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


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] pyvcp example in stepconf removed

[Alan Condit]

On Feb 4, 2009, at Feb 4, 2009--3:27 PM, alex.joni wrote:

> It's not actually removing things from pyvcp. Pyvcp still can do  
> all the
> things it did a week ago.
> The question at hand was what to include into stepconf generated  
> configs.
> (Note: stepconf is a utility which helps users to set up simple emc2
> configurations).
> So the actual question wasn't about things belonging to pyvcp or  
> not, but
> rather in a stepconf generated config.
> A stepconf config currently only supports one interface: AXIS.
> So the pyvcp embedded along with AXIS is certainly a more  
> specialized case
> then a general pyvcp use.
>
> Regards,
> Alex
>

On the subject of stepconf and pyvcp, it would be really nice if  
there was a way to define halui cmds that was not over written on  
subsequent invocations of stepconf.  Since halui commands are now  
edited into the ".ini" file, they are subsequently overwritten the  
next time that stepconf is invoked. Just an idea but a "custom.ini"  
include file like "custom.hal" might be a solution.

Alan
---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

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


--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] installing for compile

[Alan Condit]

I got all of the pieces necessary to compile emc2 on Ubuntu  
installed. Where should you install the emc2 source?  I installed it  
in the Desktop folder and compiled it but then "make install" doesn't  
work.

Thanks,
Alan

---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

Email -- [EMAIL PROTECTED]
Home-Office (503) 982-0906


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] emc2 2.10 support for other breakout boards (CandCNC mini-IO)

[Alan Condit]

I am going to update my system from 2.01 to 2.10.
Once I have updated my copy of xylotex.pinout.hal to support the  
CandCNC mini-IO breakout board. Would it be appropriate to document  
what it does (what pins it uses), why it does it (matches MACH3  
expected pinout) and add it to the configs in the cvs?  Say for  
example as "candcnc.pinout.hal"?

Alan
---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

Email -- acondit at ipns.com
Home-Office (503) 982-0906



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers