Re: [Emc-users] Open source CNC architecture

[Bari]

Machining is old tech. I want to get my parts before I even know that I 
want them.


You study old tech while I have to fix the future.

Thanks.

On 4/2/20 10:51 PM, Rafael Skodlar wrote:
I study technologies while you watch sports... 



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

Re: [Emc-users] Open source CNC architecture

[Chris Albertson]

The discussion is a little bit like what Henry Ford called "a faster horse".

Henry Ford say that if he had asked his customers what they wanted, they
would have told him "a faster horse".   But what Ford did was give them
something they did not know they coud ask for.   It is common for users to
want only slight incremental changes over what they have.   Almost no one
ever asks for a revolutinaly product.   If you are re-doing this CNC
controller for use this century you cut-out the need for real-time Linux.
Once to can place all of EMC in plain old userspace then you can manage
upgrades using the distributions native pagage system.   You simply click
"upgrade: and type in a password.   How would this work?  You simply
moove all the real-time stuff off of the Linux based system an onto cheap
hardware.



On Thu, Apr 2, 2020 at 8:54 PM Rafael Skodlar  wrote:

> On 2020-04-02 07:13, R C wrote:
> > my 2 cnts;
> >
> >
> > I work in/with HPC, and run into that stuff all the time, and it is
> > unavoidable.
>
> what stuff? It would be much easier to read old thread if related lines
> were in related place.
>
> >
> > Since HPCs run diskless, and boot in/from a network, we simply build a
> > complete new image, (and keep
> >
> > the older ones around). We never even update an image, we simply build a
> > new one from scratch, since
>
> And stop services when Saltstack, fabric, or mush could be used to
> update software without much downtime ... Nonstop rebuilds are not a
> solution to everything.
>
> >
> > an update on an existing system never works and it is easier to rebuild
> > a repo (at least in RHEL it is).
> >
> > Libraries etc, specific to applications either get relocated, or are
> > merged with the OS ones on a virtual file system.
> >
> >
> > Of course that is pretty much undo-able, impractical, unaffordable to do
> > at home, so what I do: I use different drives with
>
> That's possible since 1990s when we could buy first removable drives for
> PCs. Some were IDE, other SCSI based. Same idea as in IBM, DEC, HP, and
> other mainframe computers.
>
> >
> > separate installs (I use these now very inexpensive CRU data trays to
> > swap drives, and SSDs are really inexpensive now)
> >
> >
> > And indeed, let's not even get started on "rolling back" within an image.
> >
> >
> > containers; that's one of these things that don't seem to work
> > consistently yet. I know people (at work) that are working
> >
>
> Ever heard of Google? See more bellow
>
> > with it, developing in it, but I have not seen it work reliably/stable
> > yet. It will definitely go there, but as of yet, at least
>
> ??? It's being used in so many places that would spin your head.
>
> https://www.sdxcentral.com/articles/news/t-mobile-to-slash-30m-in-cloud-costs-with-kubernetes/2020/04/
>
> >
> > at scale, it is not working. (there are lots of issues that come down to
> > latency/timing and rdma issues and we don't
> >
> > even use real time kernels etc. most of what I do is based on RHEL and
> > application specific RHEL 'flavors')
> >
> >
> > as I said, just my 2 cts,
> >
> >
> > Ron
> I study technologies while you watch sports...
>
> --
> Rafael
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] Open source CNC architecture

[Rafael Skodlar]

On 2020-04-02 03:14, Przemek Klosowski wrote:

On Wed, Feb 19, 2020 at 1:51 AM Rafael Skodlar  wrote:



Think about LinuxCNC and it's packages. Using Slackware method you could
try to use different version of LCNC to see if it's good for your CNC
setup. If the new version fails (breaks your tool?) you could run
"cnc-admin script" to roll back, i.e. relink the app to previous version
and start it.

/opt/linuxcnc-v2.6/bin  <- binaries or scripts
/opt/linuxcnc-v2.6/etc  <- config files
...





/opt/linuxcnc-v2.7/bin
/opt/linuxcnc-v2.7/etc
...


What you suggest is not that simple. For starters, there are cross-package


It's simpler than have a full blown workstation to do the work of what a 
much smaller distribution could do. Now you have to manage much larger 
number of packages.


ls /usr/lib/ | grep python
python2.7
python3
python3.6
python3.7
python3.8

You just tell which one you want to use and all is fine. Same can be 
done with other software.


I believe that LinuxCNC would benefit with using Yocto because you can 
build software for different platforms at the same time. Used widely in 
automobile industry, avionics, and robotics as well.



dependencies, so in general you will have to carry various system libraries
required by each version. Then, modern programs use various forms of IPC,


We already have different versions of libs. Ever looked under */libs*?

Anaconda is the best utility to manage different versions of python in 
user space. Yocto takes it to another level.



so they need version specific versions of those IPC endpoints (things like
DBus, etc). IN the end, you can do it, but you replicate huge parts of the
OS. RedHat/Fedora tried to do Modularity, which is something like what you
propose except it turned out that you could have multi-version availability
but not multiversion installability (it was easy to switch versions, but
you could install only one). They put a lot of effort into making
dependencies work automatically, but in the end it turns out that lifecycle
management (patching/updating) is hard in a multi-version world: multiple
versions of multiple programs lead to combinatorial explosion of
dependencies and unresolvable conflicts when one program depends on ver. X
of something and another one on ver. Y. Currently Modularity is in retreat.



Software written so tight that it works only with a certain library but 
not on a newer one is just bad software. I hear this from other 
engineers developing for large software houses here in Silicon Valley.



The technology to do that exists---containers like Docker or Podman. The
downside is that your system is now a mess of versions, and you need to


What mess??? It's a flexible design that solves dependencies issues. 
When setup right it works automagically.



worry about patching and updating them. Containers provide a partial
solution to the Modularity problems---you can isolate such conflicts to
separate containers, but you still need to worry about lifecycle management.

If you are serious about those issues, read up on containers and
modularity---don't invent your own solutions, as a lot of people tried to
do it right and it's worth to learn from their experiences.


Using your logic nobody would ever invent or improve anything. So what 
if they failed? Somebody with make a difference then others will follow 
as usual.


When you spend as much time using and managing virtualization on servers 
as long as I have, install and setup containers etc. then ... I got 
tired of this kind of responses when you don't read on the subject 
matter before telling me I don't know anything.


The fact is that LinuxCNC is a mess in a sense because too many insist 
on basic real time functionality and top it off with full GUI instead of 
advancing from that original architecture. It helps if you study what 
large commercial manufacturers of CNC machines make. I provided links to 
some already.


How about telling others to go read about going metric and stop using 
STUPID system that is based on hundreds years dead British king butt or 
finger size?


G-code is archaic also. It's like programing PCs in assembly language in 
1980s. Some bad things just never die.


--
Rafael
Linux specialist since 1994


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

Re: [Emc-users] Open source CNC architecture

[Rafael Skodlar]

On 2020-04-02 07:13, R C wrote:

my 2 cnts;


I work in/with HPC, and run into that stuff all the time, and it is 
unavoidable.


what stuff? It would be much easier to read old thread if related lines 
were in related place.




Since HPCs run diskless, and boot in/from a network, we simply build a 
complete new image, (and keep


the older ones around). We never even update an image, we simply build a 
new one from scratch, since


And stop services when Saltstack, fabric, or mush could be used to 
update software without much downtime ... Nonstop rebuilds are not a 
solution to everything.




an update on an existing system never works and it is easier to rebuild 
a repo (at least in RHEL it is).


Libraries etc, specific to applications either get relocated, or are 
merged with the OS ones on a virtual file system.



Of course that is pretty much undo-able, impractical, unaffordable to do 
at home, so what I do: I use different drives with


That's possible since 1990s when we could buy first removable drives for 
PCs. Some were IDE, other SCSI based. Same idea as in IBM, DEC, HP, and 
other mainframe computers.




separate installs (I use these now very inexpensive CRU data trays to 
swap drives, and SSDs are really inexpensive now)



And indeed, let's not even get started on "rolling back" within an image.


containers; that's one of these things that don't seem to work 
consistently yet. I know people (at work) that are working




Ever heard of Google? See more bellow

with it, developing in it, but I have not seen it work reliably/stable 
yet. It will definitely go there, but as of yet, at least


??? It's being used in so many places that would spin your head.
https://www.sdxcentral.com/articles/news/t-mobile-to-slash-30m-in-cloud-costs-with-kubernetes/2020/04/



at scale, it is not working. (there are lots of issues that come down to 
latency/timing and rdma issues and we don't


even use real time kernels etc. most of what I do is based on RHEL and 
application specific RHEL 'flavors')



as I said, just my 2 cts,


Ron

I study technologies while you watch sports...

--
Rafael


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

Re: [Emc-users] wild hare continued.

[Gene Heskett]

On Thursday 02 April 2020 10:03:03 Ken Strauss wrote:

> > -Original Message-
> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > Sent: Thursday, April 02, 2020 8:51 AM
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] wild hare continued.
> >
> > On Thursday 02 April 2020 07:23:28 Ken Strauss wrote:
> > > > -Original Message-
> > > > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > > > Sent: Thursday, April 02, 2020 6:42 AM
> > > > To: Enhanced Machine Controller (EMC)
> > > > Subject: [Emc-users] wild hare continued.
> > > >
> > > > Greetings Andy;
> > > >
> > > > I have some of the data transfers working, but I then recall you
> > > > said G33.1 ran in metric internally.
> > > >
> > > > So if I am capturing data during the execution, but its in
> > > > inches at the nc_file origin, the captured data being passed
> > > > back needs to be *25.400 to be usefull, both as a display
> > > > and as a correction to the Z stroke.
> > > >
> > > > The fact that m66 Enn uses #5399 regardless of the nn is being
> > > > an obstacle. It means that I'll have to use some digital outputs
> > > > to tally whether or not #5399 has been read and by whom.
> > > >
> > > > Could this use be expanded to a memory location dependent on
> > > > ENN? That would greatly simplicate the gcode.
> > > >
> > > > Thanks Andy.
> > > >
> > > > Cheers, Gene Heskett
> > > > --
> > >
> > > I like the suggestion. I believe that the docs say that M66 Enn is
> > > limited to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to
> > > 7. If so, you need to allocate more than four cells to hold the
> > > most recently read value. Just a consideration to avoid breaking
> > > stuff.
> >
> > But thats expandable at load module time (top of your main hal file)
> > by passing the num_dio=NN and num_aio=NN arguments. Up to 16 of each
> > I've seen someplace. 4 is the default though.  But, I need to pass 2
> > floats to make what I want to do, works right. And I'll need to make
> > sure that variable 00 never gets mixed with variable 01 by the
> > sharing of a single #5399 placeholder for the gcode to retrieve and
> > use. I'm sure there is a reason for the #5399, but so far I don't
> > recall hearing it.
> >
> >  ???
> >
> > Thanks.
> >
> > Cheers, Gene Heskett
>
> My point was that allowing expansion of the number at HAL load time
> and allocating a numbered variable for each possible input is
> problematic. You might as well always allocate 16 and dispense with
> the parameter that changes the maximum Enn. Just a thought.
>
Not a bad one, but also wastefull of memory, for what I want to do, 2 
each of numbered vars should be sufficient. Actually, anything that 
would guarantee their separation would work. hal code runs at a 
kilohertz, but gcode is throttled by how fast the machine moves with no 
real fixed time and delay between them.  So hal may write var-B 1k+  
times while gcode is getting to the m66 En. I think I can send stuff 
above or below the while/endwhile and send a differrent var-A during the 
while/endwhile of the peck loop. But that would be yet another whole 
rewrite. Doable, but discouraging as I always run into the lack of 
separation caused by using only a single double float buffer.  Sigh.

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


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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] PMSM, STMBL Drive

[andy pugh]

On Thu, 2 Apr 2020 at 15:32, Przemek Klosowski
 wrote:

> As for the discrete respin, IRAM seems attractive because it seems to have
> a lot of diagnostic and safety features built in. A discrete based design
> has to reimplement what's needed for a safe design, which I have no idea
> how to do. Are you confident STMBL is up to it?

I have found IRAM modules easy to blow up (long before I heard of
STMBL) so they aren't _that_ special.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] PMSM, STMBL Drive

[Przemek Klosowski]

On Sat, Mar 21, 2020 at 10:13 AM andy pugh  wrote:

>
> The current STMBL design relies on a power module that is effectively
> unavailable (IRAM256-2067A2), so building one is difficult, and
> sourcing complete ones also difficult.
>

What do you think about the Ebay sources? It's a little crazy: many look
like they have been desoldered from old circuits, and the prices range from
few $ to $80+. Would you risk it?

As for the discrete respin, IRAM seems attractive because it seems to have
a lot of diagnostic and safety features built in. A discrete based design
has to reimplement what's needed for a safe design, which I have no idea
how to do. Are you confident STMBL is up to it?

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

Re: [Emc-users] wild hare continued.

[andy pugh]

On Thu, 2 Apr 2020 at 15:05, Ken Strauss  wrote:

> My point was that allowing expansion of the number at HAL load time and
> allocating a numbered variable for each possible input is problematic. You
> might as well always allocate 16 and dispense with the parameter that
> changes the maximum Enn. Just a thought.

The max is 64. I don't think we have 64 spare numbered parameters.

And I absolutely don't understand Gene's problem with getting out of
synch.  #5399 contains the one you just read with the M66.

-- 
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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Open source CNC architecture

[R C]

my 2 cnts;


I work in/with HPC, and run into that stuff all the time, and it is 
unavoidable.


Since HPCs run diskless, and boot in/from a network, we simply build a 
complete new image, (and keep


the older ones around). We never even update an image, we simply build a 
new one from scratch, since


an update on an existing system never works and it is easier to rebuild 
a repo (at least in RHEL it is).


Libraries etc, specific to applications either get relocated, or are 
merged with the OS ones on a virtual file system.



Of course that is pretty much undo-able, impractical, unaffordable to do 
at home, so what I do: I use different drives with


separate installs (I use these now very inexpensive CRU data trays to 
swap drives, and SSDs are really inexpensive now)



And indeed, let's not even get started on "rolling back" within an image.


containers; that's one of these things that don't seem to work 
consistently yet. I know people (at work) that are working


with it, developing in it, but I have not seen it work reliably/stable 
yet. It will definitely go there, but as of yet, at least


at scale, it is not working. (there are lots of issues that come down to 
latency/timing and rdma issues and we don't


even use real time kernels etc. most of what I do is based on RHEL and 
application specific RHEL 'flavors')



as I said, just my 2 cts,


Ron

On 4/2/20 4:14 AM, Przemek Klosowski wrote:

On Wed, Feb 19, 2020 at 1:51 AM Rafael Skodlar  wrote:


Think about LinuxCNC and it's packages. Using Slackware method you could
try to use different version of LCNC to see if it's good for your CNC
setup. If the new version fails (breaks your tool?) you could run
"cnc-admin script" to roll back, i.e. relink the app to previous version
and start it.

/opt/linuxcnc-v2.6/bin  <- binaries or scripts
/opt/linuxcnc-v2.6/etc  <- config files
...




/opt/linuxcnc-v2.7/bin
/opt/linuxcnc-v2.7/etc
...


What you suggest is not that simple. For starters, there are cross-package
dependencies, so in general you will have to carry various system libraries
required by each version. Then, modern programs use various forms of IPC,
so they need version specific versions of those IPC endpoints (things like
DBus, etc). IN the end, you can do it, but you replicate huge parts of the
OS. RedHat/Fedora tried to do Modularity, which is something like what you
propose except it turned out that you could have multi-version availability
but not multiversion installability (it was easy to switch versions, but
you could install only one). They put a lot of effort into making
dependencies work automatically, but in the end it turns out that lifecycle
management (patching/updating) is hard in a multi-version world: multiple
versions of multiple programs lead to combinatorial explosion of
dependencies and unresolvable conflicts when one program depends on ver. X
of something and another one on ver. Y. Currently Modularity is in retreat.

The technology to do that exists---containers like Docker or Podman. The
downside is that your system is now a mess of versions, and you need to
worry about patching and updating them. Containers provide a partial
solution to the Modularity problems---you can isolate such conflicts to
separate containers, but you still need to worry about lifecycle management.

If you are serious about those issues, read up on containers and
modularity---don't invent your own solutions, as a lot of people tried to
do it right and it's worth to learn from their experiences.

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



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

Re: [Emc-users] wild hare continued.

[Ken Strauss]

> -Original Message-
> From: Gene Heskett [mailto:ghesk...@shentel.net]
> Sent: Thursday, April 02, 2020 8:51 AM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] wild hare continued.
>
> On Thursday 02 April 2020 07:23:28 Ken Strauss wrote:
>
> > > -Original Message-
> > > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > > Sent: Thursday, April 02, 2020 6:42 AM
> > > To: Enhanced Machine Controller (EMC)
> > > Subject: [Emc-users] wild hare continued.
> > >
> > > Greetings Andy;
> > >
> > > I have some of the data transfers working, but I then recall you
> > > said G33.1 ran in metric internally.
> > >
> > > So if I am capturing data during the execution, but its in inches at
> > > the nc_file origin, the captured data being passed back needs to be
> > > *25.400 to be usefull, both as a display and as a correction to
> > > the Z stroke.
> > >
> > > The fact that m66 Enn uses #5399 regardless of the nn is being an
> > > obstacle. It means that I'll have to use some digital outputs to
> > > tally whether or not #5399 has been read and by whom.
> > >
> > > Could this use be expanded to a memory location dependent on ENN?
> > > That would greatly simplicate the gcode.
> > >
> > > Thanks Andy.
> > >
> > > Cheers, Gene Heskett
> > > --
> >
> > I like the suggestion. I believe that the docs say that M66 Enn is
> > limited to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to 7.
> > If so, you need to allocate more than four cells to hold the most
> > recently read value. Just a consideration to avoid breaking stuff.
> >
> But thats expandable at load module time (top of your main hal file) by
> passing the num_dio=NN and num_aio=NN arguments. Up to 16 of each I've
> seen someplace. 4 is the default though.  But, I need to pass 2 floats
> to make what I want to do, works right. And I'll need to make sure that
> variable 00 never gets mixed with variable 01 by the sharing of a single
> #5399 placeholder for the gcode to retrieve and use. I'm sure there is a
> reason for the #5399, but so far I don't recall hearing it.
>
>  ???
>
> Thanks.
>
> Cheers, Gene Heskett
My point was that allowing expansion of the number at HAL load time and
allocating a numbered variable for each possible input is problematic. You
might as well always allocate 16 and dispense with the parameter that
changes the maximum Enn. Just a thought.




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

Re: [Emc-users] wild hare continued.

[Gene Heskett]

On Thursday 02 April 2020 08:36:11 andy pugh wrote:

> On Thu, 2 Apr 2020 at 12:25, Ken Strauss  wrote:
> > > The fact that m66 Enn uses #5399 regardless of the nn is being an
> > > obstacle. It means that I'll have to use some digital outputs to
> > > tally whether or not #5399 has been read and by whom.
>
> I don't understand the problem. The inputs can only be read one at a
> time.
>
> M66 E0
> #50 = #5399
> M66 E1
> #51 = #5399
> M66 E2
> #52 = #5399
> M66 E3
> #53 = #5399

I'm doing similar with #<_varname> but keeping them "in-synch" is being a 
connundrum. It sure seems to be a cobble job to use a dio, set when the
motion.analog-out-NN has been written with fresh data in the hal file, 
and cleared by a read of that memory location, but I fail to see how a 
dio using an MCode can be used to tell hal the last value written has 
not been read yet.  And if the data gets scrambled, we are back to 
broken taps. The path is not 2-way.

> > I like the suggestion. I believe that the docs say that M66 Enn is
> > limited to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to
> > 7.
>
> You can have up to 64 each of analogue and digital inputs using the
> num_aio and num_dio modparams to motmod.
> http://linuxcnc.org/docs/2.8/html/man/man9/motion.9.html


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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] wild hare continued.

[Gene Heskett]

On Thursday 02 April 2020 07:23:28 Ken Strauss wrote:

> > -Original Message-
> > From: Gene Heskett [mailto:ghesk...@shentel.net]
> > Sent: Thursday, April 02, 2020 6:42 AM
> > To: Enhanced Machine Controller (EMC)
> > Subject: [Emc-users] wild hare continued.
> >
> > Greetings Andy;
> >
> > I have some of the data transfers working, but I then recall you
> > said G33.1 ran in metric internally.
> >
> > So if I am capturing data during the execution, but its in inches at
> > the nc_file origin, the captured data being passed back needs to be
> > *25.400 to be usefull, both as a display and as a correction to
> > the Z stroke.
> >
> > The fact that m66 Enn uses #5399 regardless of the nn is being an
> > obstacle. It means that I'll have to use some digital outputs to
> > tally whether or not #5399 has been read and by whom.
> >
> > Could this use be expanded to a memory location dependent on ENN?
> > That would greatly simplicate the gcode.
> >
> > Thanks Andy.
> >
> > Cheers, Gene Heskett
> > --
>
> I like the suggestion. I believe that the docs say that M66 Enn is
> limited to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to 7.
> If so, you need to allocate more than four cells to hold the most
> recently read value. Just a consideration to avoid breaking stuff.
>
But thats expandable at load module time (top of your main hal file) by 
passing the num_dio=NN and num_aio=NN arguments. Up to 16 of each I've 
seen someplace. 4 is the default though.  But, I need to pass 2 floats 
to make what I want to do, works right. And I'll need to make sure that 
variable 00 never gets mixed with variable 01 by the sharing of a single 
#5399 placeholder for the gcode to retrieve and use. I'm sure there is a 
reason for the #5399, but so far I don't recall hearing it.

 ???

Thanks.

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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] wild hare continued.

[andy pugh]

On Thu, 2 Apr 2020 at 12:25, Ken Strauss  wrote:

> > The fact that m66 Enn uses #5399 regardless of the nn is being an
> > obstacle. It means that I'll have to use some digital outputs to tally
> > whether or not #5399 has been read and by whom.

I don't understand the problem. The inputs can only be read one at a time.

M66 E0
#50 = #5399
M66 E1
#51 = #5399
M66 E2
#52 = #5399
M66 E3
#53 = #5399

> I like the suggestion. I believe that the docs say that M66 Enn is limited
> to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to 7.

You can have up to 64 each of analogue and digital inputs using the
num_aio and num_dio modparams to motmod.
http://linuxcnc.org/docs/2.8/html/man/man9/motion.9.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-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] wild hare continued.

[Ken Strauss]

> -Original Message-
> From: Gene Heskett [mailto:ghesk...@shentel.net]
> Sent: Thursday, April 02, 2020 6:42 AM
> To: Enhanced Machine Controller (EMC)
> Subject: [Emc-users] wild hare continued.
>
> Greetings Andy;
>
> I have some of the data transfers working, but I then recall you said
> G33.1 ran in metric internally.
>
> So if I am capturing data during the execution, but its in inches at the
> nc_file origin, the captured data being passed back needs to be
> *25.400 to be usefull, both as a display and as a correction to the
> Z stroke.
>
> The fact that m66 Enn uses #5399 regardless of the nn is being an
> obstacle. It means that I'll have to use some digital outputs to tally
> whether or not #5399 has been read and by whom.
>
> Could this use be expanded to a memory location dependent on ENN? That
> would greatly simplicate the gcode.
>
> Thanks Andy.
>
> Cheers, Gene Heskett
> --
I like the suggestion. I believe that the docs say that M66 Enn is limited
to nn=0 to 3. Tormach's PathPilot appears to allow nn=0 to 7. If so, you
need to allocate more than four cells to hold the most recently read value.
Just a consideration to avoid breaking stuff.




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

[Emc-users] wild hare continued.

[Gene Heskett]

Greetings Andy;

I have some of the data transfers working, but I then recall you said 
G33.1 ran in metric internally.

So if I am capturing data during the execution, but its in inches at the 
nc_file origin, the captured data being passed back needs to be 
*25.400 to be usefull, both as a display and as a correction to the 
Z stroke.

The fact that m66 Enn uses #5399 regardless of the nn is being an 
obstacle. It means that I'll have to use some digital outputs to tally 
whether or not #5399 has been read and by whom.

Could this use be expanded to a memory location dependent on ENN? That 
would greatly simplicate the gcode.

Thanks Andy.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 


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

Re: [Emc-users] Open source CNC architecture

[Przemek Klosowski]

On Wed, Feb 19, 2020 at 1:51 AM Rafael Skodlar  wrote:

>
> Think about LinuxCNC and it's packages. Using Slackware method you could
> try to use different version of LCNC to see if it's good for your CNC
> setup. If the new version fails (breaks your tool?) you could run
> "cnc-admin script" to roll back, i.e. relink the app to previous version
> and start it.
>
> /opt/linuxcnc-v2.6/bin  <- binaries or scripts
> /opt/linuxcnc-v2.6/etc  <- config files
> ...
>


> /opt/linuxcnc-v2.7/bin
> /opt/linuxcnc-v2.7/etc
> ...
>
What you suggest is not that simple. For starters, there are cross-package
dependencies, so in general you will have to carry various system libraries
required by each version. Then, modern programs use various forms of IPC,
so they need version specific versions of those IPC endpoints (things like
DBus, etc). IN the end, you can do it, but you replicate huge parts of the
OS. RedHat/Fedora tried to do Modularity, which is something like what you
propose except it turned out that you could have multi-version availability
but not multiversion installability (it was easy to switch versions, but
you could install only one). They put a lot of effort into making
dependencies work automatically, but in the end it turns out that lifecycle
management (patching/updating) is hard in a multi-version world: multiple
versions of multiple programs lead to combinatorial explosion of
dependencies and unresolvable conflicts when one program depends on ver. X
of something and another one on ver. Y. Currently Modularity is in retreat.

The technology to do that exists---containers like Docker or Podman. The
downside is that your system is now a mess of versions, and you need to
worry about patching and updating them. Containers provide a partial
solution to the Modularity problems---you can isolate such conflicts to
separate containers, but you still need to worry about lifecycle management.

If you are serious about those issues, read up on containers and
modularity---don't invent your own solutions, as a lot of people tried to
do it right and it's worth to learn from their experiences.

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