Re: [Emc-developers] Mesa 7I80HDT needed

[Peter C. Wallace]

On Tue, 18 Apr 2023, Chris Helgesen wrote:


Date: Tue, 18 Apr 2023 09:09:45 -0400
From: Chris Helgesen 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Mesa 7I80HDT needed

Hello,

Apologies for bothering the developer's list with this. I have a Hurco KM3
I did a LinuxCNC-based retrofit on during the Jurassic period. I need to
replace the host PC, and I've reached the end of the road for my Mesa PCI
interface card.

Does anyone have a new or fully-functional Mesa 7I80HDT they would be
willing to sell? I'm told the lead time is currently around two months. I
need the 50-pin dual-row headers for existing ribbon cables to a Mesa servo
card and two Opto-22 I/O boards.

I could make this very easy for anyone going to the LinuxCNC meeting at
Tormach, as Steve Stallings will be there and has kindly offered to pick
stuff up for me.

While I'm here, many thanks to all the developers for the excellent work
and support!

Chris Helgesen

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



We have one left (kept from the proto run to duplicate customer issues)
But by now I dont think there are any issues, so I can put it on our 
webstore later today.



Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] Arc Bug, help needed.

[Peter C. Wallace]

On Wed, 7 Dec 2022, andy pugh wrote:


Date: Wed, 7 Dec 2022 21:54:41 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Arc Bug, help needed.


On Wed, 7 Dec 2022 at 20:36, John Thornton  wrote:

I can confirm the bug is in the 2.9 branch that is currently in Debian,
I'm unable to build a RIP on 2.9 to see if it's still there as I get




metric or imperial config?
Did you run the test command in G20 or G21?
NO_FORCE_HOMING?

What CPU are you running? (It is getting to the point that I am wondering
if that matters)



I have no issue with G20 or G21 with current master

(with g2 x0 y0 j5 z-2 f1000 as the first linuxCNC motion at startup)

of course X,Y must be 0 at the start

Peter Wallace


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

Re: [Emc-developers] Arc Bug, help needed.

[Peter C. Wallace]

On Wed, 7 Dec 2022, andy pugh wrote:


Date: Wed, 7 Dec 2022 11:50:09 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Arc Bug, help needed.

In February I fixed this bug:
https://github.com/LinuxCNC/linuxcnc/issues/1528

But, it seems, I failed to properly consider full-circle spiral arcs, and
the test was wrong.

https://github.com/LinuxCNC/linuxcnc/issues/2169
(Note that this issue report was _not_ raised by the original reporter, 
and furthermore seems to show a _different_ issue.


I investigated and found a test case that I could reproduce, and put in a
fix for that. (linked in the issue report above)

However it is reported that the original bug (that I have never 
reproduced) still exists.


Here is the problem description:

"if open axis.

Comand g2 x0 y0 j5 z-2 f1000.

The machine not execution g2 , but only Z-2."

I think that the system needs to be set up for immediate homing to 0,0,0 
as I have an unconfirmed report that this specific problem does not occur 
if the axes have moved. (But then the test cases that Tom_L shows in the 
bug report has the third arc going wrong too)



I don't get the bug with 2.10, immediate homing, first move after linuxcnc 
loaded or with previous motion either with  MDI or as 2 line ngc:


g2 x0 y0 j5 z-2 f1000
m2

Preview and path are OK


Peter Wallace


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

Re: [Emc-developers] curious about the ethernet protocol

[Peter C. Wallace]

On Mon, 18 Apr 2022, andy pugh wrote:


Date: Mon, 18 Apr 2022 00:59:07 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] curious about the ethernet protocol

On Sat, 16 Apr 2022 at 00:42, Torsten Curdt via Emc-developers

 wrote:


IIUC the GCODE interpreter runs in the non-realtime part. It sends the step
instructions to a card to execute the steps. This is obvious when using a
LPT port, but how does this work via Ethernet?

Snip-


As far as I know an ethernet smoothstepper does not do this. I don't
even think that they "buffer" as is often suggested. In fact I think
that they move all of the "tc" on to the hardware. So probing and
spindle-synched motion is handled inside the card, not on the host
controller.



An external card with a TC probably has multiple levels of buffers...

(back when we made some MACH 3 compatible hardware, it was in fact buffered
PVTA motion so Mach3 did the trajectory planning and the external hardware
just played out a PVTA sequence from a FIFO)




--
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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] curious about the ethernet protocol

[Peter C. Wallace]

On Sun, 17 Apr 2022, Torsten Curdt via Emc-developers wrote:


Date: Sun, 17 Apr 2022 13:47:40 +0200
From: Torsten Curdt via Emc-developers 
To: EMC developers 
Cc: Torsten Curdt 
Subject: Re: [Emc-developers] curious about the ethernet protocol


Maybe finding an old parallel port machine might still be the easier
route
:-/


Better yet, a pci-e buss and a 5i25 card.




5I25 is PCI
6I25 is PCIE
7I92 is Ethernet

Mesa still has 6I25s and 7I92s

a 5I25, 6I25 or 7I92 are basically interchangable

Ethernet is especially good If there is a long distance between the
control PC and the drive box (larger machines)



Unfortunately that circles back to the mesa availability problems :-(
Would a 7i92 also work?

Seems I either need to go with Remora or a Parallel BOB.
And I would probably have to get a PCI/PCIe Parallel Port.

two parports lots faster than a mobo parport.




mobo = motherboard?

How come the 5i25 is faster?

cheers,
Torsten

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] curious about the ethernet protocol

[Peter C. Wallace]

On Sat, 16 Apr 2022, Torsten Curdt wrote:


Date: Sat, 16 Apr 2022 18:09:08 +0200
From: Torsten Curdt 
To: Torsten Curdt via Emc-developers 
Cc: Peter C. Wallace 
Subject: Re: [Emc-developers] curious about the ethernet protocol


How come you send the velocity commands and not target positions? Size of
the positioning data I assume?



Basically just following the LinuxCNC model of having the host be the
locus of control. This is the basic difference between buffered systems
like Mach and LinuxCNC. By having the LinuxCNC host be the controller
you gain a number of advantages:

1. The external hardware is simpler (and more uniform)
2. The more complex parts of the control are located on a host
with basically unlimited memory and CPU capabilities so real time behaviour
is extensible by a large group of users/developers using standard tools.
3. Specifically, returning actual position allows use of the following
error mechanism for tuning and robust fault detection without a side
channel of status information.



I get the general idea. But I am still a little shy on the details.

It sounds on a LPT port setup the host sends every individual step to the
port.
Now if the motor has an encoder LinuxCNC could read the position every 1ms
and make it a host based closed loop system. And I get the appeal.
But people are also using LinuxCNC with a BOB and Open Loop Steppers
without an encoder.
So it sounds like the feedback is missing there.


Its still there but internal to the stepgen component



Now for the Mesa card setup.
IIUC LinuxCNC does not send every individual step over ethernet. Instead it
sends motion controls commands.
You said they are velocity commands. So it should be something along the
lines of:

"x+1000 steps in 1500ms"
"y-100 steps in 500ms"



Simpler that that, linuxCNC simply sends the step rate
(scaled for the hardware)


On top of that the Mesa card will report back the position of the motors
(steps from 0?) every 1ms to the host.


Not steps from 0 but rather relative position as a signed 32 bit number
 16.16 (whole steps.fractional steps)

(LinuxCNCs position is a FP double)



Is that correct?


cheers,
Torsten



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] curious about the ethernet protocol

[Peter C. Wallace]

On Sat, 16 Apr 2022, Torsten Curdt via Emc-developers wrote:


Date: Sat, 16 Apr 2022 14:15:14 +0200
From: Torsten Curdt via Emc-developers 
To: Torsten Curdt via Emc-developers 
Cc: Torsten Curdt 
Subject: Re: [Emc-developers] curious about the ethernet protocol



The way the Mesa stepgen works currently is basically copied from the
software
stepgen component. The host PC sends velocity commands to the stepgen
hardware
(a 48 bit DDS) and reads the stepgen current position (all at the nominal
1 KHz
servo thread rate) Then a feedback loop in LinuxCNC or hal corrects for
the
minor position errors due to differences in timebases, delays between
position
reads and velocity writes, velocity setting resolution limits etc. This
feedback
loop keeps the position error each sample time to a small fraction of an
external step.



How come you send the velocity commands and not target positions? Size of
the positioning data I assume?



Basically just following the LinuxCNC model of having the host be the
locus of control. This is the basic difference between buffered systems
like Mach and LinuxCNC. By having the LinuxCNC host be the controller
you gain a number of advantages:

1. The external hardware is simpler (and more uniform)
2. The more complex parts of the control are located on a host
with basically unlimited memory and CPU capabilities so real time behaviour
is extensible by a large group of users/developers using standard tools.
3. Specifically, returning actual position allows use of the following
error mechanism for tuning and robust fault detection without a side
channel of status information.



I can see this to be super useful when there is an external encoder - so
linuxcnc is in full control.
But what's the benefit with e.g. Servos and Closed Loop Stepper that have
their internal encoder and control loop?

I guess some Servos allow you to read the position error via e.g.
serial/modbus - but that will be all but real time at maybe 57k baud.
Thought it would still be nice if LinuxCNC could use that information
coming in.
But I bet this is already possible :)

(Another crazy(?) thought I had was to have an acceleration sensor as
incoming feedback. To help with servo parameterization.)


And now I hope I don't get lynched for asking:

How is that ethernet protocol different from the Mach3 ethernet protocol?
Are there significant differences between the protocols that would

prohibit

LinuxCNC speaking the Mach3 ethernet protocol?



Mach is not real time so needs buffered hardware/software in the remote
device
that stores a series of moves (perhaps PVT segments)  and plays them out
while
the host keeps the buffer full. This is not compatible with LinuxCNC's
motion
model where all motion hardware access is real time.



It feels like sending the velocity commands over ethernet also means some
kind of buffering, but I guess the 1kHz feedback loop is the big difference
here.

But then again I am wondering how this helps with a system that doesn't
have encoder feedback as such.
Will the mesa card just report back where the motor should be? That seems
to defeat the intent.

Much appreciate the details, Peter.
I would probably not ask these devil's advocats/learning questions if I
could get my hands on a 7i96E ;)

cheers,
Torsten

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] curious about the ethernet protocol

[Peter C. Wallace]

On Sat, 16 Apr 2022, Torsten Curdt via Emc-developers wrote:


Date: Sat, 16 Apr 2022 01:23:49 +0200
From: Torsten Curdt via Emc-developers 
To: emc-developers@lists.sourceforge.net
Cc: Torsten Curdt 
Subject: [Emc-developers] curious about the ethernet protocol

Hey there,

I was wondering the following - and mainly really to understand how
LinuxCNC works.
Since I couldn't get a proper answer in the user chat I thought I would try
here.

IIUC the GCODE interpreter runs in the non-realtime part. It sends the step
instructions to a card to execute the steps. This is obvious when using a
LPT port, but how does this work via Ethernet?

Are the steps compressed into instructions and then applied on the Mesa
cards?
Poking around it seems like there are motion commands and status commands?
So it probably sends "go there" and "where are you" and the card generates
the steps required and reports back. Does that sound right? Is there a
definition of the protocol to look at?
I assume the code of what gets pushed to the Mesa's must be somewhere, too.


The way the Mesa stepgen works currently is basically copied from the software 
stepgen component. The host PC sends velocity commands to the stepgen hardware 
(a 48 bit DDS) and reads the stepgen current position (all at the nominal 1 KHz 
servo thread rate) Then a feedback loop in LinuxCNC or hal corrects for the 
minor position errors due to differences in timebases, delays between position 
reads and velocity writes, velocity setting resolution limits etc. This feedback 
loop keeps the position error each sample time to a small fraction of an 
external step.





And now I hope I don't get lynched for asking:
How is that ethernet protocol different from the Mach3 ethernet protocol?
Are there significant differences between the protocols that would prohibit
LinuxCNC speaking the Mach3 ethernet protocol?



Mach is not real time so needs buffered hardware/software in the remote device 
that stores a series of moves (perhaps PVT segments)  and plays them out while 
the host keeps the buffer full. This is not compatible with LinuxCNC's motion 
model where all motion hardware access is real time.




Or maybe no one knows or cares? But I was wondering if
implementing the protocol could be another alternative to flashing Remora
to supported boards.

While waiting for Mesa stocks to recover, I am really just curious to
understand the technical side of the LinuxCNC vs Mach3 comparison.

cheers,
Torsten

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



Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] Has anyone used Halscope recently?

[Peter C. Wallace]

On Mon, 24 Jan 2022, andy pugh wrote:


Date: Mon, 24 Jan 2022 00:16:55 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Has anyone used Halscope recently?

I just tried to use it on a 2.8.2 install, and it didn't look right.
The sliders have lost their "tracks", and are just simple circles.

Possibly a theme / desktop thing?



Yeah, looks like something has changed. I get the same thing with the current 
master on Mint20




--
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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Mesa 7i76 more than 5 step motor interfaces possible?

[Peter C. Wallace]

On Tue, 5 Oct 2021, Juergen Gnoss wrote:


Date: Tue, 5 Oct 2021 03:51:44 +
From: Juergen Gnoss 
Reply-To: EMC developers 
To: "emc-developers@lists.sourceforge.net"

Subject: [Emc-developers] Mesa 7i76 more than 5 step motor interfaces
possible?

Thanks for the response, Andy.

Is it possible to connect one 7i76 and one 7i78 on a 5i25?

Ju



Yes, or just add one of those common "Mach 5 axis" parallel port breakouts




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] building/running linuxcnc from source question

[Peter C. Wallace]

On Sat, 25 Sep 2021, Jeff Epler wrote:


Date: Sat, 25 Sep 2021 17:18:19 -0500
From: Jeff Epler 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] building/running linuxcnc from source question

I have a potential fix at https://github.com/LinuxCNC/linuxcnc/pull/1275

Jeff




This does work without numpy, I somehow messed up applying the patch



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



Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] building/running linuxcnc from source question

[Peter C. Wallace]

On Mon, 27 Sep 2021, Marc Wang wrote:


Date: Mon, 27 Sep 2021 13:44:21 +
From: Marc Wang 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] building/running linuxcnc from source question

Hi Peter,

I ended up figuring out the error. I was missing numpy in my dependencies. You 
can either install it through "pip3 install numpy" or "sudo apt-get install 
python3-numpy"


Regards,
marc


Yes, I did that and its fixed. (still have DRO font issues however)


-Original Message-
From: Peter C. Wallace 
Sent: September 25, 2021 5:07 PM
To: EMC developers 
Subject: Re: [Emc-developers] building/running linuxcnc from source question

On Sat, 18 Sep 2021, Marc Wang wrote:


Date: Sat, 18 Sep 2021 20:43:11 +
From: Marc Wang 
Reply-To: EMC developers 
To: "emc-developers@lists.sourceforge.net"

Subject: [Emc-developers] building/running linuxcnc from source question

Hi,

I managed to compile linuxcnc from source and all the tests run successfully. I 
was wondering if anybody else got the following error. When I run the file 
./scripts/linuxcnc. I get the following error :

File "/home/marc/Documents/linuxcnc/linuxcnc/lib/python/glnav.py", line 118, in 
glRotateScene
   mat = [i for i in itertools.chain(*mat.tolist())]
AttributeError: 'c_double_Array_4_Array_4' object has no attribute 'tolist'

the error is fairly straight forward. I am just wondering if this is a bug or 
just that I have the wrong version of pyopengl.

I am running Ubuntu 20.04.3 LTS with an 5.10.59-rt52 kernel. I have pyopengl 
3.1.0 installed with python 3.8.10.

Regards,
Marc

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



Same error

Mint 20.2, Python 3.8.10, pyopengl 3.1.0, 4.19.206-rt87


Peter Wallace
Mesa Electronics



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


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] building/running linuxcnc from source question

[Peter C. Wallace]

On Sat, 18 Sep 2021, Marc Wang wrote:


Date: Sat, 18 Sep 2021 20:43:11 +
From: Marc Wang 
Reply-To: EMC developers 
To: "emc-developers@lists.sourceforge.net"

Subject: [Emc-developers] building/running linuxcnc from source question

Hi,

I managed to compile linuxcnc from source and all the tests run successfully. I 
was wondering if anybody else got the following error. When I run the file 
./scripts/linuxcnc. I get the following error :

File "/home/marc/Documents/linuxcnc/linuxcnc/lib/python/glnav.py", line 118, in 
glRotateScene
   mat = [i for i in itertools.chain(*mat.tolist())]
AttributeError: 'c_double_Array_4_Array_4' object has no attribute 'tolist'

the error is fairly straight forward. I am just wondering if this is a bug or 
just that I have the wrong version of pyopengl.

I am running Ubuntu 20.04.3 LTS with an 5.10.59-rt52 kernel. I have pyopengl 
3.1.0 installed with python 3.8.10.

Regards,
Marc

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



Same error

Mint 20.2, Python 3.8.10, pyopengl 3.1.0, 4.19.206-rt87


Peter Wallace
Mesa Electronics



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

[Emc-developers] Sserial bit type parameters

[Peter C. Wallace]

How difficult would it be to add bit type parameters
to the sserial driver? (they are ignored currently)


Peter Wallace
Mesa electronics



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

Re: [Emc-developers] Pncconf Step Timing Limit

[Peter C. Wallace]

On Wed, 30 Jun 2021, John Thornton wrote:


Date: Wed, 30 Jun 2021 16:44:54 -0500
From: John Thornton 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Pncconf Step Timing Limit

Peter,

Do most Mesa stepgens have the same limit?

JT


~164 usec is the longest on cards with 100 MHz ClockLow =
7I76E,7I80,7I90,7I92,7I93,7I94,7I95,7I96,7I97,7I98

Cards with 50 MHz or 33 MHz ClockLow will have ~330 usec
or ~500 usec maximum timings.



On 6/30/2021 2:53 PM, Peter C. Wallace wrote:

On Wed, 30 Jun 2021, Chris Morley wrote:


Date: Wed, 30 Jun 2021 19:37:30 +
From: Chris Morley 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Pncconf Step Timing Limit

Yes... what limit do you think is reasonable?
Chris



I would think 50 usec would be ok for the slowest hardware

The stepgen firmware has a limit of ~164 usec for all timings



 Original message 
From: John 
Date: 2021-06-30 7:49 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] Pncconf Step Timing Limit

Hi Chris,

Can you increase the step timing to > 12,000?

"When I was using the parallel port, the step and hold were 12000 and
3500.  The software maxes this out at 1 for the 7i92 so I used that
instead of 12000.

X axis will move, but NOT very smoothly.  Y and Z do not move at all.

All 3 axis are identical, with the exception of the length of the
leadscrew (china cnc3040 machine). Same motor, same leadscrew pitch,
same wiring, etc.  The motor driver is a TB6560 (not great, but works
fine for my tinkering)."

After advising the chap to edit the ini file and set the step timing
where he needed for his drives.

"Ok, I finally have 3 axis working smoothly.  Editing the ini file and
playing with the step and hold times did the trick.

My apologies for being a little cranky, but I was working on it all last
week and into the weekend and was just hitting the brick wall. I had
assumed that the PncConf was showing the true max limits (step/hold) of
the card, so I didn't think there was anything else to be done."

Thanks
JT



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

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Pncconf Step Timing Limit

[Peter C. Wallace]

On Wed, 30 Jun 2021, Chris Morley wrote:


Date: Wed, 30 Jun 2021 19:37:30 +
From: Chris Morley 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Pncconf Step Timing Limit

Yes... what limit do you think is reasonable?
Chris



I would think 50 usec would be ok for the slowest hardware

The stepgen firmware has a limit of ~164 usec for all timings



 Original message 
From: John 
Date: 2021-06-30 7:49 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] Pncconf Step Timing Limit

Hi Chris,

Can you increase the step timing to > 12,000?

"When I was using the parallel port, the step and hold were 12000 and
3500.  The software maxes this out at 1 for the 7i92 so I used that
instead of 12000.

X axis will move, but NOT very smoothly.  Y and Z do not move at all.

All 3 axis are identical, with the exception of the length of the
leadscrew (china cnc3040 machine). Same motor, same leadscrew pitch,
same wiring, etc.  The motor driver is a TB6560 (not great, but works
fine for my tinkering)."

After advising the chap to edit the ini file and set the step timing
where he needed for his drives.

"Ok, I finally have 3 axis working smoothly.  Editing the ini file and
playing with the step and hold times did the trick.

My apologies for being a little cranky, but I was working on it all last
week and into the weekend and was just hitting the brick wall.  I had
assumed that the PncConf was showing the true max limits (step/hold) of
the card, so I didn't think there was anything else to be done."

Thanks
JT



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

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Mesaflash Versions

[Peter C. Wallace]

On Tue, 22 Jun 2021, andy pugh wrote:


Date: Tue, 22 Jun 2021 00:11:49 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Mesaflash Versions

The LinuxCNC repo carries Mesaflash 3.4.0~pre1, a tag released
something over a year ago.

Who is in charge of Mesaflash releasing? Does the buildbot make
packages, or is that a manual process?

--
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





I dont know if anyone is in charge... but I did change it recently (May 27)
I dont think the buildbot builds images


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

Re: [Emc-developers] hal_port

[Peter C. Wallace]

On Wed, 10 Mar 2021, andy pugh wrote:


Date: Wed, 10 Mar 2021 23:57:28 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] hal_port

On Wed, 10 Mar 2021 at 23:56, andy pugh  wrote:

On Wed, 10 Mar 2021 at 23:55, andy pugh  wrote:

https://github.com/DuttonIndustrial/linuxcnc/tree/29127782da2da3e26b8d5e9c233cbaa9fea653a4/configs/sim/axis/laser


And 
https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/laserpower.comp

https://github.com/DuttonIndustrial/linuxcnc/blob/29127782da2da3e26b8d5e9c233cbaa9fea653a4/src/hal/components/raster.comp



Thanks for digging that up!



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

[Emc-developers] hal_port

[Peter C. Wallace]

Is there any example code for hal_port?
I would like to try writing a driver for the DataPainter
and PktUART modules.

(and by write I mean copy and hack)


Peter Wallace
Mesa Electronics



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

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

[Peter C. Wallace]

On Sat, 27 Feb 2021, Curtis Dutton wrote:


Date: Sat, 27 Feb 2021 08:08:49 -0500
From: Curtis Dutton 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] I wish I had a super size 8i20

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

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

Has this ever been discussed before?

-Curt



BTW I was looking at finally writing some driver code for the
DataPainter firmware module  using hal_port. The hal_port
manual page references example code but I cant seem to find it...





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



Peter Wallace
Mesa Electronics


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

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

[Peter C. Wallace]

On Sat, 27 Feb 2021, andy pugh wrote:


Date: Sat, 27 Feb 2021 13:26:39 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] I wish I had a super size 8i20

On Sat, 27 Feb 2021 at 13:09, Curtis Dutton  wrote:

I'm driving the spindle and servos with 8i20's. I
just love them they are great.

I like the 8i20 (I have 5 in use) but I think I like the STMBL more.

And it might be an easier proposition to put a much bigger power stage
on an STMBL than it is to make a new 8i20.


I would think a STMBL like device with a standard connector
to an separate power stage would be a good idea.

Peter Wallace
Mesa Electronics




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

Re: [Emc-developers] [PCW too] rpi 5.10 rt preempt

[Peter C. Wallace]

On Tue, 23 Feb 2021, Gene Heskett wrote:


Date: Tue, 23 Feb 2021 11:07:19 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] [PCW too] rpi 5.10 rt preempt

On Tuesday 23 February 2021 04:12:19 Thomas J Powderly wrote:


I'm getting 73.1us base latency already

and need about 20 for my step timings worse case,

so 80us base thread is ng


Mine with std threads is much worse ATM, but mc is busy unpacking the src
zip.  And doing it over my local net. And thats seriously hogging cpu
cycles. And, the pi was also busy building linuxcnc-master :)

But now I have another problem. One for Peter.

mesaflash can readhmid of a 5i25 just fine, well enough I can see its the
wrong firmware in it, no pwmgens, but won't write a new one. Complains
all the file headers are wrong:

gene@Hardinge1:~/linuxcnc/hostmot2-firmware-5i25$ sudo mesaflash --device
5i25 --program prob_rfx2.PIN
ERROR: Board 5I25 doesn't support FPGA resetting.
gene@Hardinge1:~/linuxcnc/hostmot2-firmware-5i25$ sudo mesaflash --device
5i25 --verify prob_rfx2.PIN
Checking file... Invalid bitfile header!

But it doesn't look contaminated to me.

What did I forget to do?

Thanks Peter.

Cheers, Gene Heskett


You are trying to write a .pin (a text pinout description) file instead of a
.bit (Xilinx  firmware) file



--
"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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] My pi4b build is broken

[Peter C. Wallace]

On Mon, 1 Feb 2021, Gene Heskett wrote:


Date: Mon, 1 Feb 2021 13:01:52 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] My pi4b build is broken

On Monday 01 February 2021 11:10:39 Peter C. Wallace wrote:


On Mon, 1 Feb 2021, Gene Heskett wrote:

Date: Mon, 1 Feb 2021 11:01:16 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] My pi4b build is broken

On Monday 01 February 2021 10:45:06 Peter C. Wallace wrote:

On Mon, 1 Feb 2021, Gene Heskett wrote:


That would be advantageous. But the 3 phase stepper servo's I've
fallen in love with don't make it available externally. They do have
an error output you can apply to the e-stop though and that is
downright handy.

Is there an index in the cable back to the driver from the encoder
on those? IDK.


I dont think any of the commom closed loop stepper drives have an
index on the encoder, but most step/dir driven servos do.


Does this mean the 2 phase closed loop stuff has it? One of the reasons I
migrated to the 3 phase is the smaller step, 1.2 as opposed to 1.8
degrees for a full step. That, and the machine noise is 5% of a 2 phaser
because these drivers only use coil current enough to do as they are
told. If the error goes up, so does the current.  At working speeds it
moves like Casper the ghost. With the 1600 oz 2 phase on the Z, it shook
a 12" crescent wrench out of the chip pan, or tried like hell.  I had to
put a 1/4 round fence on the edge of the keyboard table where the gear
box used to be as I broke keyboards and mice on the cement floor so many
times. Vibrated off.  These are sweet, motor and driver at $120 a copy.

Thank you Peter.



I dont think any of the closed loop stepper drives support index
(since having and index or absolute encoder is not needed for these
drives unlike normal 3 phase servo drives)

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] My pi4b build is broken

[Peter C. Wallace]

On Mon, 1 Feb 2021, Gene Heskett wrote:


Date: Mon, 1 Feb 2021 11:01:16 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] My pi4b build is broken

On Monday 01 February 2021 10:45:06 Peter C. Wallace wrote:


On Mon, 1 Feb 2021, Gene Heskett wrote:


That would be advantageous. But the 3 phase stepper servo's I've fallen
in love with don't make it available externally. They do have an error
output you can apply to the e-stop though and that is downright handy.

Is there an index in the cable back to the driver from the encoder on
those? IDK.



I dont think any of the commom closed loop stepper drives have an
index on the encoder, but most step/dir driven servos do.

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] My pi4b build is broken

[Peter C. Wallace]

On Mon, 1 Feb 2021, Gene Heskett wrote:


Date: Mon, 1 Feb 2021 10:20:41 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] My pi4b build is broken

On Monday 01 February 2021 10:03:39 Peter C. Wallace wrote:


On Mon, 1 Feb 2021, Gene Heskett wrote:

Date: Mon, 1 Feb 2021 09:55:57 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] My pi4b build is broken

Greetings all, from your pi canary;

As of late last night, building linuxcnc on the rpi4 has worked, but
fails to run. Build scripts attached, they have Just Worked for
months. lots of errors I've been meaning at ask about but all are in
the docs generation stage. 235 unit tests all passed.

Errors are usually can't make .pdf from .jpg or .png. Must be over
100 of those.

Installed the built .deb's and trying to run it gets this:
==
pi@rpi4:/media/pi/workspace $ linuxcnc -l
LINUXCNC - 2.9.0~pre0
Machine configuration directory is
'/home/pi/linuxcnc/configs/sheldon-lathe' Machine configuration file
is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
rmmod: ERROR: Module spi_bcm2835 is not currently loaded <-looks
like an error hm2_rpspi: ERROR: Failed to execute '/sbin/rmmod
spi_bcm2835' <-ditto, but config doesn't use it hm2_rpspi: Platform:
Raspberry Pi 4 Model B Rev 1.1
hm2_rpspi: Base address 0xfe00 size 0x0180
hm2_rpspi: Mapped peripherals from 0xfe00 (size 0x0180) to
gpio:0x0xb47f5000, spi:0x0xb47f9000, aux:0x0xb480a000 hm2_rpspi:
SPI0/CE0 clock rate: 41666000/2500 Hz, VPU clock rate: 55000
Hz hm2_rpspi: SPI0/CE0 write clock rate calculated: 39285714 Hz
(clkdiv=14) hm2_rpspi: SPI0/CE0 read clock rate calculated: 2500
Hz (clkdiv=22) hm2_rpspi: SPI0/CE0 Valid cookie matched
hm2_rpspi: SPI0/CE0 Base: hm2_7i90.0
hm2/hm2_7i90.0: Low Level init 0.15
hm2/hm2_7i90.0: MD 2: 3x IOPort v0: accepted, using 3
hm2/hm2_7i90.0: MD 0: 1x Hostmot2 DPLL v0: accepted, using 1
hm2/hm2_7i90.0: MD 1: 1x Watchdog v0: accepted, using 1
hm2/hm2_7i90.0: MD 3: 4x Encoder v2: accepted, using 4
hm2/hm2_7i90.0: MD 4: 2x PWMGen v0: accepted, using 1
hm2/hm2_7i90.0: MD 5: 4x StepGen v2: accepted, using 4
hm2/hm2_7i90.0: MD 6: 1x LED v0: accepted, using 1
hm2/hm2_7i90.0: 72 I/O Pins used:
hm2/hm2_7i90.0: IO Pin 000 (P1-01): StepGen #0, pin Step
(Output) hm2/hm2_7i90.0: IO Pin 001 (P1-03): StepGen #0, pin
Direction (Output) hm2/hm2_7i90.0: IO Pin 002 (P1-05): StepGen
#1, pin Step (Output) hm2/hm2_7i90.0: IO Pin 003 (P1-07):
StepGen #1, pin Direction (Output) hm2/hm2_7i90.0: IO Pin 004
(P1-09): Encoder #0, pin A (Input) hm2/hm2_7i90.0: IO Pin 005
(P1-11): Encoder #2, pin A (Input) hm2/hm2_7i90.0: IO Pin 006
(P1-13): Encoder #0, pin B (Input) hm2/hm2_7i90.0: IO Pin 007
(P1-15): Encoder #2, pin B (Input) hm2/hm2_7i90.0: IO Pin 008
(P1-17): Encoder #0, pin Index (Input) hm2/hm2_7i90.0: IO Pin
009 (P1-19): Encoder #2, pin Index (Input) hm2/hm2_7i90.0: IO
Pin 010 (P1-21): Encoder #1, pin A (Input) hm2/hm2_7i90.0: IO
Pin 011 (P1-23): Encoder #3, pin A (Input) hm2/hm2_7i90.0: IO
Pin 012 (P1-25): Encoder #1, pin B (Input) hm2/hm2_7i90.0: IO
Pin 013 (P1-27): Encoder #3, pin B (Input) hm2/hm2_7i90.0: IO
Pin 014 (P1-29): Encoder #1, pin Index (Input) hm2/hm2_7i90.0:
IO Pin 015 (P1-31): Encoder #3, pin Index (Input) hm2/hm2_7i90.0:
 IO Pin 016 (P1-33): StepGen #2, pin Step (Output) hm2/hm2_7i90.0:
  IO Pin 017 (P1-35): StepGen #2, pin Direction (Output)
hm2/hm2_7i90.0: IO Pin 018 (P1-37): StepGen #3, pin Step
(Output) hm2/hm2_7i90.0: IO Pin 019 (P1-39): StepGen #3, pin
Direction (Output) hm2/hm2_7i90.0: IO Pin 020 (P1-41): PWMGen
#0, pin Out0 (PWM or Up) (Output) hm2/hm2_7i90.0: IO Pin 021
(P1-43): PWMGen #0, pin Out1 (Dir or Down) (Output) hm2/hm2_7i90.0:
   IO Pin 022 (P1-45): IOPort
hm2/hm2_7i90.0: IO Pin 023 (P1-47): IOPort
hm2/hm2_7i90.0: IO Pin 024 (P2-01): IOPort
hm2/hm2_7i90.0: IO Pin 025 (P2-03): IOPort
hm2/hm2_7i90.0: IO Pin 026 (P2-05): IOPort
hm2/hm2_7i90.0: IO Pin 027 (P2-07): IOPort
hm2/hm2_7i90.0: IO Pin 028 (P2-09): IOPort
hm2/hm2_7i90.0: IO Pin 029 (P2-11): IOPort
hm2/hm2_7i90.0: IO Pin 030 (P2-13): IOPort
hm2/hm2_7i90.0: IO Pin 031 (P2-15): IOPort
hm2/hm2_7i90.0: IO Pin 032 (P2-17): IOPort
hm2/hm2_7i90.0: IO Pin 033 (P2-19): IOPort
hm2/hm2_7i90.0: IO Pin 034 (P2-21): IOPort
hm2/hm2_7i90.0: IO Pin 035 (P2-23): IOPort
hm2/hm2_7i90.0: IO Pin 036 (P2-25): IOPort
hm2/hm2_7i90.0: IO Pin 037 (P2-27): IOPort
hm2/hm2_7i90.0: IO Pin 038 (P2-29): IOPort
hm2/hm2_7i90.0: IO Pin 039 (P2-31): IOPort
hm2/hm2_7i90.0: IO Pin 040 (P2-33): IOPort
hm2/hm2_7i90.0: IO Pin 041 (P2-35): IOPort
hm2/hm2_7i90.0: IO Pin 042 (P2-37): IOPort
hm2/hm2_

Re: [Emc-developers] My pi4b build is broken

[Peter C. Wallace]

On Mon, 1 Feb 2021, Gene Heskett wrote:


Date: Mon, 1 Feb 2021 09:55:57 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] My pi4b build is broken

Greetings all, from your pi canary;

As of late last night, building linuxcnc on the rpi4 has worked, but
fails to run. Build scripts attached, they have Just Worked for months.
lots of errors I've been meaning at ask about but all are in the docs
generation stage. 235 unit tests all passed.

Errors are usually can't make .pdf from .jpg or .png. Must be over 100
of those.

Installed the built .deb's and trying to run it gets this:
==
pi@rpi4:/media/pi/workspace $ linuxcnc -l
LINUXCNC - 2.9.0~pre0
Machine configuration directory is '/home/pi/linuxcnc/configs/sheldon-lathe'
Machine configuration file is '7i90-axis.ini'
Starting LinuxCNC...
Found file(REL): ./hm2-7i90-stepper.hal
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
rmmod: ERROR: Module spi_bcm2835 is not currently loaded <-looks like an error
hm2_rpspi: ERROR: Failed to execute '/sbin/rmmod spi_bcm2835' <-ditto, but 
config doesn't use it
hm2_rpspi: Platform: Raspberry Pi 4 Model B Rev 1.1
hm2_rpspi: Base address 0xfe00 size 0x0180
hm2_rpspi: Mapped peripherals from 0xfe00 (size 0x0180) to 
gpio:0x0xb47f5000, spi:0x0xb47f9000, aux:0x0xb480a000
hm2_rpspi: SPI0/CE0 clock rate: 41666000/2500 Hz, VPU clock rate: 55000 
Hz
hm2_rpspi: SPI0/CE0 write clock rate calculated: 39285714 Hz (clkdiv=14)
hm2_rpspi: SPI0/CE0 read clock rate calculated: 2500 Hz (clkdiv=22)
hm2_rpspi: SPI0/CE0 Valid cookie matched
hm2_rpspi: SPI0/CE0 Base: hm2_7i90.0
hm2/hm2_7i90.0: Low Level init 0.15
hm2/hm2_7i90.0: MD 2: 3x IOPort v0: accepted, using 3
hm2/hm2_7i90.0: MD 0: 1x Hostmot2 DPLL v0: accepted, using 1
hm2/hm2_7i90.0: MD 1: 1x Watchdog v0: accepted, using 1
hm2/hm2_7i90.0: MD 3: 4x Encoder v2: accepted, using 4
hm2/hm2_7i90.0: MD 4: 2x PWMGen v0: accepted, using 1
hm2/hm2_7i90.0: MD 5: 4x StepGen v2: accepted, using 4
hm2/hm2_7i90.0: MD 6: 1x LED v0: accepted, using 1
hm2/hm2_7i90.0: 72 I/O Pins used:
hm2/hm2_7i90.0: IO Pin 000 (P1-01): StepGen #0, pin Step (Output)
hm2/hm2_7i90.0: IO Pin 001 (P1-03): StepGen #0, pin Direction (Output)
hm2/hm2_7i90.0: IO Pin 002 (P1-05): StepGen #1, pin Step (Output)
hm2/hm2_7i90.0: IO Pin 003 (P1-07): StepGen #1, pin Direction (Output)
hm2/hm2_7i90.0: IO Pin 004 (P1-09): Encoder #0, pin A (Input)
hm2/hm2_7i90.0: IO Pin 005 (P1-11): Encoder #2, pin A (Input)
hm2/hm2_7i90.0: IO Pin 006 (P1-13): Encoder #0, pin B (Input)
hm2/hm2_7i90.0: IO Pin 007 (P1-15): Encoder #2, pin B (Input)
hm2/hm2_7i90.0: IO Pin 008 (P1-17): Encoder #0, pin Index (Input)
hm2/hm2_7i90.0: IO Pin 009 (P1-19): Encoder #2, pin Index (Input)
hm2/hm2_7i90.0: IO Pin 010 (P1-21): Encoder #1, pin A (Input)
hm2/hm2_7i90.0: IO Pin 011 (P1-23): Encoder #3, pin A (Input)
hm2/hm2_7i90.0: IO Pin 012 (P1-25): Encoder #1, pin B (Input)
hm2/hm2_7i90.0: IO Pin 013 (P1-27): Encoder #3, pin B (Input)
hm2/hm2_7i90.0: IO Pin 014 (P1-29): Encoder #1, pin Index (Input)
hm2/hm2_7i90.0: IO Pin 015 (P1-31): Encoder #3, pin Index (Input)
hm2/hm2_7i90.0: IO Pin 016 (P1-33): StepGen #2, pin Step (Output)
hm2/hm2_7i90.0: IO Pin 017 (P1-35): StepGen #2, pin Direction (Output)
hm2/hm2_7i90.0: IO Pin 018 (P1-37): StepGen #3, pin Step (Output)
hm2/hm2_7i90.0: IO Pin 019 (P1-39): StepGen #3, pin Direction (Output)
hm2/hm2_7i90.0: IO Pin 020 (P1-41): PWMGen #0, pin Out0 (PWM or Up) (Output)
hm2/hm2_7i90.0: IO Pin 021 (P1-43): PWMGen #0, pin Out1 (Dir or Down) 
(Output)
hm2/hm2_7i90.0: IO Pin 022 (P1-45): IOPort
hm2/hm2_7i90.0: IO Pin 023 (P1-47): IOPort
hm2/hm2_7i90.0: IO Pin 024 (P2-01): IOPort
hm2/hm2_7i90.0: IO Pin 025 (P2-03): IOPort
hm2/hm2_7i90.0: IO Pin 026 (P2-05): IOPort
hm2/hm2_7i90.0: IO Pin 027 (P2-07): IOPort
hm2/hm2_7i90.0: IO Pin 028 (P2-09): IOPort
hm2/hm2_7i90.0: IO Pin 029 (P2-11): IOPort
hm2/hm2_7i90.0: IO Pin 030 (P2-13): IOPort
hm2/hm2_7i90.0: IO Pin 031 (P2-15): IOPort
hm2/hm2_7i90.0: IO Pin 032 (P2-17): IOPort
hm2/hm2_7i90.0: IO Pin 033 (P2-19): IOPort
hm2/hm2_7i90.0: IO Pin 034 (P2-21): IOPort
hm2/hm2_7i90.0: IO Pin 035 (P2-23): IOPort
hm2/hm2_7i90.0: IO Pin 036 (P2-25): IOPort
hm2/hm2_7i90.0: IO Pin 037 (P2-27): IOPort
hm2/hm2_7i90.0: IO Pin 038 (P2-29): IOPort
hm2/hm2_7i90.0: IO Pin 039 (P2-31): IOPort
hm2/hm2_7i90.0: IO Pin 040 (P2-33): IOPort
hm2/hm2_7i90.0: IO Pin 041 (P2-35): IOPort
hm2/hm2_7i90.0: IO Pin 042 (P2-37): IOPort
hm2/hm2_7i90.0: IO Pin 043 (P2-39): IOPort
hm2/hm2_7i90.0: IO Pin 044 (P2-41): IOPort
hm2/hm2_7i90.0: IO Pin 045 (P2-43): IOPort
hm2/hm2_7i90.0: IO Pin 046 (P2-45): IOPort
hm2/hm2_7i90.0: IO Pin 047 (P2-47): IOPort
hm2/hm2_7i90.0: IO Pin 048 (P3-01): IOPort

Re: [Emc-developers] Withdraw Pi support?

[Peter C. Wallace]

On Mon, 18 Jan 2021, Gene Heskett wrote:


Date: Mon, 18 Jan 2021 15:22:12 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Withdraw Pi support?

On Monday 18 January 2021 14:05:19 Peter C. Wallace wrote:


On Sun, 17 Jan 2021, Gene Heskett wrote:



URL to buy one, maybe more?  Found it, too much usefull i/o has
disappeared, so I'm not that interested. I am using all 4 usb jacks
+ spi at 40 megabit write and 25 megabit reads, but I suspect that
would crash and burn at much lower speeds with a cable to a 7i90
much longer than the inch I'm using. And I'm not willing to dedicate
the only wired ethernet port to a 7c80.


The 7C80 (and 7C81) are SPI interfaced devices


Thats much better Peter, but how long can the cable be?


It need not be longer than 1.5 inches or so since the RPI mounts on top of (and 
get power from) the 7C80/7C81 via a 40 pin flat cable






Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] Withdraw Pi support?

[Peter C. Wallace]

On Sun, 17 Jan 2021, Gene Heskett wrote:



URL to buy one, maybe more?  Found it, too much usefull i/o has
disappeared, so I'm not that interested. I am using all 4 usb jacks +
spi at 40 megabit write and 25 megabit reads, but I suspect that would
crash and burn at much lower speeds with a cable to a 7i90 much longer
than the inch I'm using. And I'm not willing to dedicate the only wired
ethernet port to a 7c80.


The 7C80 (and 7C81) are SPI interfaced devices


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Withdraw Pi support?

[Peter C. Wallace]

On Sun, 17 Jan 2021, Gene Heskett wrote:


Date: Sun, 17 Jan 2021 14:08:05 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Withdraw Pi support?

On Sunday 17 January 2021 12:06:42 Matt Shaver wrote:


On Sun, 17 Jan 2021 15:17:57 +

andy pugh  wrote:

The current linuxcnc-served Raspberry Pi realtime kernel does not
work with the latest hardware revision of the raspberry Pi.


Does it work for the 3B+? If so, maybe just add a note to the docs
that this is the hardware you have to use. In my own experience the
Pi3 works well, the Pi4 seems kind of shaky...


I don't want to be seen as starting an argument with the legendary Matt
Shaver, but I can't let that go by. It is NOT the least bit shaky here
Matt, I have a larger 5 amp psu, which is also running 360 GB worth of
SSD's on usb3 adaptors, and a 7i90HD i/o board + 3 7i42TA's and a small
350 WA UPS on mine, and the only reason it gets rebooted is if a library
it needs gets updated.

Uptime is 2 days ATM, but was north of 2 months when I rebooted it to
replace a json library on Thursday evening. I can't recall the last time
I had an actual crash, its that rare. I don't use that ultra puny wall
wart psu supplied, its well known to not be big enough as also is the
OTG port it plugs into. I am feeding it directly on the 40 pin header. I
also have 4 teeny heat sinks stuck on it, cooled by an ex-video card
ball bearing fan. A 12 volt fan running on 5 volts.  And its building
LinuxCNC from github about 5 to 7 times a week as commits are being
made. A full build is getting close to 2 hours as docs are being added.

Here, with a decent supply and a small bit of cooling, it Just Works.


Thanks,
Matt



Thats my experience also, I have > 6 months uptime on my 4G RPI4 running 
linuxCNC+Axis over SPI on a 7C80. This is with a simple stick-on heatsink

It has never crashed or reported a latency error (1 KHz servo thread)



(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 8.1 planning.

[Peter C. Wallace]

On Sun, 22 Nov 2020, andy pugh wrote:


Date: Sun, 22 Nov 2020 12:16:52 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] 8.1 planning.

I am thinking that it is time for 8.1 to release some bug fixes and

support for some Mesa cards that were missed out.


Does anyone have anything in the pipeline that they would like to see included?

--
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



Not a LinuxCNC thing but I would drop the disfunctional wicd in favor of 
netmanager



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

Re: [Emc-developers] pwmgen, mesa version, man page is?

[Peter C. Wallace]

On Mon, 26 Oct 2020, Gene Heskett wrote:


Date: Mon, 26 Oct 2020 04:00:31 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] pwmgen, mesa version, man page is?

On Monday 26 October 2020 00:27:31 Peter C. Wallace wrote:


On Sun, 25 Oct 2020, Gene Heskett wrote:

Date: Sun, 25 Oct 2020 23:54:34 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] pwmgen, mesa version, man page is?

On Sunday 25 October 2020 22:51:15 Peter C. Wallace wrote:

On Sun, 25 Oct 2020, Gene Heskett wrote:

Date: Sun, 25 Oct 2020 21:50:25 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] pwmgen, mesa version, man page is?

Greetings all;

Some confusion about useing the mesa pwmgens in a 5i25 with the
5i25_7i76_1px2d.bit file loaded.  this bitfile fails to wire up
the dir output, but is as close to driveing a stock bob on p2 as
there is.


I dont think this is the case, Both PWMgens have direction outputs


If my tracing is correct, pwmgen.01's dir s/b on the std bob at
Zdir, adjacent to its output on Zstep from the pwmgen.01.  Its dir
is nowhere to be found that I can find. pwmgen.00 s/b step/dir4 in
both polarities. These may be working but I'm haveing a hard time
correlating the mouse clicks to check both and hold a meter or scope
probe at the same time.


I just tried the 7i76_1px2d pinfile source code on a 7I92
and it works as expected:

setting PWM 00 or 01 to a 0.5 value results in a 50 % duty cycle
waveform with DIR low

setting PWM 00 or 01 to -0.5 value results in a 50 % duty cycle
waveform with DIR high


But. But. I don't have a 7i92, nor do I have a free ethernet port to
drive it with. I have a std sainsmart bob on the 5i25's p2. The crimp on
cable was bad at first but thats been repaired with new connectors.


The 7I92 config will work identically to the 5I25 config, that was my point




That pwmgen.01's dir output s/b on the 5i25.0.gpio.021, aka header pin5,
aka YDIR.  So I've edited the .hal slightly different, and I can now see
the signals at the 5i25.0.gpio.006.in and gpio.007.in for axis A with a
halmeter.



?? using 5i25_7i76_1px2d:

PWMgen00s direction is on GPIO 8 (P3 DB25 pin 5)
PWMgen00s PWM is on GPIO 9 (P3 DB25 pin 6)

PWMgen01s direction is on GPIO 25 (P2 DB25 pin 5)
PWMgen02s PWM is on GPIO 26 (P2 DB25 pin 6)

Note I anm not referencing header pins but always DB25 pins



And dittos for pwmgen.01 for gpio pins 25 & 26 for the spindle.  Now to
wire it that way since it isn't.  These sainsmart BoB boards are cheap,
well built and almost indestructable, but chasing a signal thru one that
doesn't name outputs by pin # is a cast iron bitch.





Thank you, Peter.

[...]

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 <http://geneslinuxbox.net:6309/gene>


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] pwmgen, mesa version, man page is?

[Peter C. Wallace]

On Sun, 25 Oct 2020, Gene Heskett wrote:


Date: Sun, 25 Oct 2020 23:54:34 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] pwmgen, mesa version, man page is?

On Sunday 25 October 2020 22:51:15 Peter C. Wallace wrote:


On Sun, 25 Oct 2020, Gene Heskett wrote:

Date: Sun, 25 Oct 2020 21:50:25 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] pwmgen, mesa version, man page is?

Greetings all;

Some confusion about useing the mesa pwmgens in a 5i25 with the
5i25_7i76_1px2d.bit file loaded.  this bitfile fails to wire up the
dir output, but is as close to driveing a stock bob on p2 as there
is.


I dont think this is the case, Both PWMgens have direction outputs


If my tracing is correct, pwmgen.01's dir s/b on the std bob at Zdir,
adjacent to its output on Zstep from the pwmgen.01.  Its dir is nowhere
to be found that I can find. pwmgen.00 s/b step/dir4 in both polarities.
These may be working but I'm haveing a hard time correlating the mouse
clicks to check both and hold a meter or scope probe at the same time.


I just tried the 7i76_1px2d pinfile source code on a 7I92
and it works as expected:

setting PWM 00 or 01 to a 0.5 value results in a 50 % duty cycle waveform with 
DIR low


setting PWM 00 or 01 to -0.5 value results in a 50 % duty cycle waveform with 
DIR high







In order to use both pwmgens, I have added and ABS module for each
pwmgen, feeding it the pwmgen.xx.value, and using the sign bit
output in place of the missing pwmgen.01 mode=1 DIR line. But
because I needed both polarities to control the H-bridge, something
I can get out of pwmgen.00, I've swapped the spindle duties to
pwmgen.01 which only needs one dir signal, and put the A axis on
pwmgen.00 where I can get the complimentary DIRs out of TB3 on the
7i76D.


IF pwmgen.00 drives all 4 pins of stepgen4, which it should, I'll have
the signals I need to drive the olimex boards dir inputs. But I cannot
find the DIR from pwmgen.01 anyplace on the bob, hence the abs.S.sign
module.


It almost works. I can run the spindle either direction but it runs
it slightly rough because the pwm output is in groups of pulses,
making perhaps 20 pulses, then stopping for a few milliseconds, then
making another group of pulses. Looking at the encoder output with a
real scope, the speed variation is nearly 50% while averaging the
requested 100 revs.

I thought  my encoder was going out but its still tightly coupled to
the motor shaft, so there isn't any slippage unless its internal,
and I have about made up my mind to obtain another encoder.

Until I started up wireing up that car seat H-bridge from olymex to
drive the A axis as a servo. That motors encoder is wired up in hal,
but is not yet connected to the bobs inputs 1,2,3 for encoder.01's
IDX,encA,encB.  The IDX will be a switch on the BS-1, used for a
home switch, not wired up yet because the motor is yt to be mounte.

So there is not any A feedback.  For testing, pid.A.FF0 is 1, the
remaining pid inputs are all zero'd.

So theoreticly pid.A.output is straight thru from the [] keys.  The
cobbled up abs.A.sign works, giving a plus DIR signal to which ever
side of the top half of H-bridge you want the motor to run, while
the bottom half is pulsed by the pwm. And it switches the stepgen#3
outputs at exactly 0.0 at the pwmgen.00.value just like I
expected.

But the pulses from that pwmgen.00 are coming out in groups, then
silence, basicly acting quite like the other pwmgen.01 now driving
the spindle rather noisily.


It sounds a bit like you have the wrong PWM mode set or a hardware
issue


mode 1 for both.


The PWM generator is described  in the hostmot2 manual page


Aha, the one place I've not looked recently.  And the first thing I note
is that the separate read and write of gpio isn't needed. So I took
those out.  And now the spindle only runs the first time, running wide
open ignoreing any further run commands until LCNC has been restarted.

I'll rescope the boot module and pwmgen outputs tomorrow first thing.


I'm stumped. The DC supplies running the cards are solid at 5.1 and
12.05 for field power.



Has anyone a clue what I might be fighting with? The FUNCTION's
shown in the man page I assume do not exist for the mesa versions,
so there are no addf lines for them.  Should there be?
There are these addf's first:
addfhm2_5i25.0.read_gpioservo-thread
addfhm2_5i25.0.read servo-thread
couple more pages of addf's
# and finally, update machine
addf   hm2_5i25.0.write_gpioservo-thread
addf   hm2_5i25.0.write servo-thread

I do note that hm2_5i25.0.dpll.phase-error-us is dancing wildly,
over about a +-50 range, much wilder than the other 2 machines that
have that pin in the halmeter menu. They are only showing a +-1 or 2
dance.

Removing the gpio read/writes did not seem to effect the above noisy
signal.  I wonder it the bios in that Dell uses

Re: [Emc-developers] pwmgen, mesa version, man page is?

[Peter C. Wallace]

On Sun, 25 Oct 2020, Gene Heskett wrote:


Date: Sun, 25 Oct 2020 21:50:25 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] pwmgen, mesa version, man page is?

Greetings all;

Some confusion about useing the mesa pwmgens in a 5i25 with the
5i25_7i76_1px2d.bit file loaded.  this bitfile fails to wire up the dir
output, but is as close to driveing a stock bob on p2 as there is.


I dont think this is the case, Both PWMgens have direction outputs



In order to use both pwmgens, I have added and ABS module for each
pwmgen, feeding it the pwmgen.xx.value, and using the sign bit output in
place of the missing pwmgen.01 mode=1 DIR line. But because I needed
both polarities to control the H-bridge, something I can get out of
pwmgen.00, I've swapped the spindle duties to pwmgen.01 which only needs
one dir signal, and put the A axis on pwmgen.00 where I can get the
complimentary DIRs out of TB3 on the 7i76D.

It almost works. I can run the spindle either direction but it runs it
slightly rough because the pwm output is in groups of pulses, making
perhaps 20 pulses, then stopping for a few milliseconds, then making
another group of pulses. Looking at the encoder output with a real
scope, the speed variation is nearly 50% while averaging the requested
100 revs.

I thought  my encoder was going out but its still tightly coupled to the
motor shaft, so there isn't any slippage unless its internal, and I have
about made up my mind to obtain another encoder.

Until I started up wireing up that car seat H-bridge from olymex to drive
the A axis as a servo. That motors encoder is wired up in hal, but is
not yet connected to the bobs inputs 1,2,3 for encoder.01's
IDX,encA,encB.  The IDX will be a switch on the BS-1, used for a home
switch, not wired up yet because the motor is yt to be mounte.

So there is not any A feedback.  For testing, pid.A.FF0 is 1, the
remaining pid inputs are all zero'd.

So theoreticly pid.A.output is straight thru from the [] keys.  The
cobbled up abs.A.sign works, giving a plus DIR signal to which ever side
of the top half of H-bridge you want the motor to run, while the bottom
half is pulsed by the pwm. And it switches the stepgen#3 outputs at
exactly 0.0 at the pwmgen.00.value just like I expected.

But the pulses from that pwmgen.00 are coming out in groups, then
silence, basicly acting quite like the other pwmgen.01 now driving the
spindle rather noisily.



It sounds a bit like you have the wrong PWM mode set or a hardware issue

The PWM generator is described  in the hostmot2 manual page



I'm stumped. The DC supplies running the cards are solid at 5.1 and 12.05
for field power.





Has anyone a clue what I might be fighting with? The FUNCTION's shown in
the man page I assume do not exist for the mesa versions, so there are
no addf lines for them.  Should there be?
There are these addf's first:
addfhm2_5i25.0.read_gpioservo-thread
addfhm2_5i25.0.read servo-thread
couple more pages of addf's
# and finally, update machine
addf   hm2_5i25.0.write_gpioservo-thread
addf   hm2_5i25.0.write servo-thread

I do note that hm2_5i25.0.dpll.phase-error-us is dancing wildly, over
about a +-50 range, much wilder than the other 2 machines that have that
pin in the halmeter menu. They are only showing a +-1 or 2 dance.

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)
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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 2.8 release update.

[Peter C. Wallace]

On Sat, 1 Aug 2020, andy pugh wrote:


Date: Sat, 1 Aug 2020 02:44:55 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.8 release update.

On Sat, 1 Aug 2020 at 02:16, Peter C. Wallace  wrote:



Can the 2.9 hostmot2 driver additions, bugfixes  be included?




Can you be more specific?
Which particular ones?

basically hm2_eth inm inmux xy2mod stepgen pwmgen hostmot2-manpage
but they all share so many files updating all of mesa-hostmot2
seems like it would be simpler


--
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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.8 release update.

[Peter C. Wallace]

On Sat, 1 Aug 2020, andy pugh wrote:


Date: Sat, 1 Aug 2020 01:46:26 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] 2.8 release update.

Does anyone here know of any let or hindrance why 2.8 can't be

released this weekend?

We have Spanish and Chinese doc translations on the way, and I have
given up on French.

I have made a working ISO, just needs a new pull of the release
version to be finalised.

I have documented installing with the Pi preempt kernel. I _think_ it
works the first time. There are issues with file over-writing after
that, which _might_ be fixable with a "Replaces" in the kernel debs. I
haven't looked in to this in detail.
http://linuxcnc.org/docs/2.8/html/getting-started/getting-linuxcnc.html#_installing_on_raspbian_10
Testing of these instructions would be welcomed.

You can't test the update case, the packages are not in the repository yet.

But you can try out a not-quite-release .iso file
http://www.linuxcnc.org/temp/2.8_test4.iso




Can the 2.9 hostmot2 driver additions, bugfixes  be included?


--
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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 2.8 Situation

[Peter C. Wallace]

On Tue, 9 Jun 2020, Alec Ari via Emc-developers wrote:


Date: Tue, 9 Jun 2020 19:56:32 + (UTC)
From: Alec Ari via Emc-developers 
To: EMC developers 
Cc: Alec Ari 
Subject: Re: [Emc-developers] 2.8 Situation

I want what I want because I'm five and I want it now. I spent 6 years working 
my ass off on RTAI and none of you could give a fuck less.


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





I for one am very grateful for your work getting 64 bit RTAI working with 
LinuxCNC


Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] 2.8 Situation

[Peter C. Wallace]

On Tue, 9 Jun 2020, andy pugh wrote:


Date: Tue, 9 Jun 2020 11:25:40 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] 2.8 Situation

I had hoped to release 2.8 at Easter, but hit a roadblock.

My plan was to offer both preempt-rt and RTAI ISOs for fresh installs with
Debian Buster, and packages for both realtime systems for the other
supported OSs too.
Unfortunately, despite a lot of effort on the part of Alec and a lesser
amount by myself we have not managed to make the RTAI system exit cleanly
under all circumstances.

Specifically a script that starts realtime, loads an instance of the abs
component and then exists will cause a kernel lock up after hundreds to
thousands of cycles.
Unfortunately this means that runtests will frequently crash the buildbot,
so is a more serious problem than it might seem.

As far as I know the system is reliable and stable while actually running
LinuxCNC.

There is a similar problem simply loading and unloading the RTAI
kernel modules (No LinuxCNC code involved), but that takes tens of
thousands of cycles (typically) to show so may be an entirely different
issue.

Unfortunately many existing users are likely to have machines that won't
work acceptably with preempt-rt and, whilst 2.8 does run on 32-bit Wheezy +
RTAI I really would like to be offering an upgrade path to a supported OS.

So I don't really know what to do.

--
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


How likely are LinuxCNC bugs to RT specific? (that is, what test coverage do 
you get by just running the tests on Preempt-RT)


As far as the buildbot goes could the RTAI tests be done on another system with 
a hardware watchdog?


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

Re: [Emc-developers] Mesa Sigma5ABS module

[Peter C. Wallace]

On Mon, 30 Mar 2020, Curtis Dutton wrote:


Date: Mon, 30 Mar 2020 16:33:13 -0400
From: Curtis Dutton 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Mesa Sigma5ABS module

Hi all,

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

Within hostmot2-firmware,

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

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


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

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

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

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


At one time there was only 32K of useable address space because the EPP 
interfaced cards used the MSB of the address as an address autoinc flag. Since 
EPP interfaced cards are basically legacy devices at this point, newer hm2 
modules use addresses > 0x7FFF and currently B000,C000,D000,E000,F000 are all 
free.


At some point, complile time allocation of module addresses might make sense,
but that's a fairly large change so I think I'll wait until I run out of address
space until I do that.

Note, there's no harm in overlap as long as you dont expect to use the 
overlapping modules in the same configuration






Thanks,
  Curt

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



Peter Wallace
Mesa Electronics



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

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

[Peter C. Wallace]

On Wed, 25 Mar 2020, Curtis Dutton wrote:


Date: Wed, 25 Mar 2020 14:02:39 -0400
From: Curtis Dutton 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] pktuart -> rs-485

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


BTW a simple way to bisect the testing process is to simply loop back the FPGA 
TX line to the FPGA RX line, to eliminate any issues with TXEN, polarities, 
RS-485 driver hookup etc etc



Peter Wallace
Mesa Electronics


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

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

[Peter C. Wallace]

On Wed, 25 Mar 2020, Curtis Dutton wrote:


Date: Wed, 25 Mar 2020 12:10:22 -0400
From: Curtis Dutton 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] pktuart -> rs-485

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


Did you mean 7I85?



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




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

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




I can't seem to get them to work.


Are the RS-485 enables connected to PktUART TXEN pins and do they have the 
correct polarity? (Active low)



Note that there is a fairly recent fix in the TXEN delay function of the PKtUART 
so it should probably be set to 0 for testing




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

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

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

Do I even have the correct approach here?


Thanks,
  Curtis

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] nother Q for Peter C.W.

[Peter C. Wallace]

On Sat, 7 Mar 2020, Gene Heskett wrote:


Date: Sat, 7 Mar 2020 07:06:41 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] nother Q for  Peter C.W.

On Saturday 07 March 2020 00:13:38 Gene Heskett wrote:


On Friday 06 March 2020 21:50:15 Jon Elson wrote:

On 03/06/2020 05:38 PM, Gene Heskett wrote:

I have now put 2 ATD667LSG's on this block and have failed to get
a working index pulse into linuxcnc thru the encoder index pin of
a 7i76D.


Note these sensors are open-collector, so need a pull-up
resistor.


I've mounted it branded face against a block of alu, with a green
3 pin socket to allow unplugging it quickly, and I jbwelded a
piece of a nail to the side of the drawbar cap/bolt retainer at
the top of the spindle, but I can't get a false out of it at any
orientation of the nail or a tool waved past it.


The sensor is on the end where the leads come out of the
package, but at right angles to the
leads.  That's the "branded face".  So, it sounds like you
have them mounted backwards.


That cross patterned face is then a target to be machined into the
mount to locate it more precisely?  I'm in the house but I now seem to
recall that its the smooth side that's facing the gear in the lathe.
Duh. It takes a 16mm projector lens and damned strong light to read
the text printed on the "branded face". What the hell were they
thinking?

You're saying that the depressed cross in the 5% smaller face is not
the sensed face? That the crossed pattern should be the face glued to
the mount? In that event I also have them wired reversed polarity.
Which shouldn't hurt them as they are rated for up to 18 volts of
reversed voltage. But by now, I'll have to do some chisel work to
remove and likely wreck a 2nd one.  Sigh. This is what they mean when
they say an education costs money... I only bought 6, paying about $2
more from digikey because all the $6 ebay ones were in the middle of
the virus in china and 6 weeks away.

Thats also an excellent example of a piss-poor 14 page document they
supply. That cross grooved face is much easier to identify. And mount
to the smooth face, the jbweld oozing out can also cause lead shorts
much easier.


The gear tooth needs to wipe sideways across the sensor to
be registered.  So, a gear
tooth that is parallel to the leads will be sensed as it
wipes across the face of the sensor.


Or in this case, 1/2" of a 2" nail, jbwelded to the outside of the
drawbar retainer cap which will swipe across the smooth face as the
spindle rotates.

Now I am pissed at me.


Motion of the tooth will be at right angles to the leads.

Check if the sensor +5 V is drawing any current (should be
about 7 mA).  Are you sure you have not
connected to the "test" output (pin 3)?  They don't say what
this pin does, just tell you "tie to ground or
leave open".


Which I've always clipped off...


Jon


Thank you Jon.


Now, it looks to me that the only non-ambiguous drawing in that whole
document is the one on the lower left on page 8.

But read the text. It seems to me that the rotation reversal is going to
diddle the vertical positioning if there is any encoder counter reset
allowed while the locked condition is in effect. It doesn't give me any
confidence that the vertical positioning will be error free at all.
What I do know for sure is that if because the tap is too big to pull in
one g33.1 pass due to lack of motor power and I have close to 2hp I can
surge it to, and I write the rigid tap routine to peck the operation by
driveing the tap only 1/4 to 1/2 a turn per "Peck" until the depth has
been obtained, that the repeated passes give me an obviously loose fit
to a bolt, which I have until now blamed on a backlash take-up error.

What I haven't done is played with the backlash to see if the somewhat
sloppy thread obtained by peck tapping can be improved. But I also don't
know if a counter reset is done anyplace but at the instant the
down-stroke is started. But that text tends to tell me that since the
pulse polarity depends on the rotational direction, then the phasing
relationship is going to be diddled by quite a few counts at the bottom
of the hole when the turnaround and backout move is begun.

How can one determine if thats the case?

Its going to be very hard to see on the halscope unless a 50 u-s base
thread just to run the halscope is setup, something I don't have now.
This is, I think. probably in the 5i25 firmware and I'm not qualified to
troll thru that. I can't even imagine how that might be alleviated, even
by an automatic edge detector. Even if the polarity is reversed with the
direction of rotation, it has to be reset probably several counts ahead
of the true zero point as the nail crosses over the hall effects gap,
before it can send that edge again on the next rotation. So which edge
do we use to get the least error? Seems to me the first edge should be
ignored because that would be the reset edge to be thrown away. 

Re: [Emc-developers] nother Q for Peter C.W.

[Peter C. Wallace]

On Fri, 6 Mar 2020, Gene Heskett wrote:


Date: Fri, 6 Mar 2020 18:38:53 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] nother Q for  Peter C.W.

I have now put 2 ATD667LSG's on this block and have failed to get a
working index pulse into linuxcnc thru the encoder index pin of a 7i76D.

I've mounted it branded face against a block of alu, with a green 3 pin
socket to allow unplugging it quickly, and I jbwelded a piece of a nail
to the side of the drawbar cap/bolt retainer at the top of the spindle,
but I can't get a false out of it at any orientation of the nail or a
tool waved past it.

I've tried 2 new ones now, and they  appear to be stuck high/true when
the connector is made up, but goes false about 1 second after unplugging
it. Attempting to measure the current gets a worst case of about 1.2
u-amps to ground, and that is not enough to pull it down to false unless
the dvm is replaced by a short to ground and shows zilch current to the
5 volts.

Trying to measure input current by inserting the dvm between its output
and the encoder-index in looks like a small capacitor charging, but
drops to zero current in nominally 1 second and stays there.

W4-W5-W6 have been tried both ways, but to the left s/b ttl and
everything except the ATS667 is ttl.  Its supposed to be able to sink 25
ma up to 70 ma with a 12 volt supply, but its only getting 4.92 volts.

3 of them have been working on 5 volts on the lathe for going on 3 years.
Worked fine till the goop went to hell because it dissolves in 0-W20
synthetic spindle oil.

I'm bumfuzzled.  Obviously I'm doing something wrong but what?

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





You can test the 7I76D index input in TTL mode by simply shorting it to ground.
The encoder inputs have 2K pullups to 5V. You can read the index pin status in 
hal, for a 5I25/6I25 and a 7I76 (encoder 0) that pin would be:


hm2_5i25.0.encoder.00.input-index

I would check the ATS667 5V and GND connections, sounds like something is open

Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Thu, 5 Mar 2020, Gene Heskett wrote:


Date: Thu, 5 Mar 2020 10:42:19 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Thursday 05 March 2020 09:25:01 Peter C. Wallace wrote:


On Wed, 4 Mar 2020, Gene Heskett wrote:

Date: Wed, 4 Mar 2020 22:12:47 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Wednesday 04 March 2020 12:52:09 andy pugh wrote:

On Wed, 4 Mar 2020 at 17:26, Peter C. Wallace 

wrote:

It was first added to 2.8 and them merged into 2.7 before the
2.7.15 release AFAIK


I think that they were added in 2010:
https://github.com/LinuxCNC/linuxcnc/commit/44586b831e1ef5e82600319
0ab 317cda76b6e8e3#diff-912d11dfa52738be509f63e4ff1922a4 (And that
commit also includes documentation of the pins)


Sort of. But it does provide some hints as to how to utilize it to
improve control, If you have encoder feedback on axis axis then you
could feed the feedback.deriv pin with the velocity of that axis's
encoder. But from reading that, I fail to deduct a source for
cmd.deriv. I am envisioning a differential, for instance between
current command and previous command or maybe a sum2 with one input
set for a gain of -1 and an rc lag from the command input to the
other input giving a differential output according to the charge
across the cap. Since we don't have a cap in hal components, we'ed
have to use a low pass.  But I quickly run out of imagination as to
the rc time constant to synthesize.

just discussing the howto's would I think be educational for those
of us who never got the transcendental stuff in school 70+ years
ago.

Help?

Thanks


Normally you would just connect the joint velocity pin to the PID
command derivative


Ok, but thats the signal I disconnected around 2 years back to get rid of
an instant following error for a movement of 1/10 the MIN_ERROR. So
hooking it back back up now does what to my FF# settings?



It requres somewhat different tuning because of differening delays
in the TPs idea of velocity and velocity calculated in PID via DP/DT
Changing anything now is likely a waste of time





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 <http://geneslinuxbox.net:6309/gene>


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


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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



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 <http://geneslinuxbox.net:6309/gene>


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, Gene Heskett wrote:


Date: Wed, 4 Mar 2020 22:12:47 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Wednesday 04 March 2020 12:52:09 andy pugh wrote:


On Wed, 4 Mar 2020 at 17:26, Peter C. Wallace  wrote:

It was first added to 2.8 and them merged into 2.7 before the
2.7.15 release AFAIK


I think that they were added in 2010:
https://github.com/LinuxCNC/linuxcnc/commit/44586b831e1ef5e826003190ab
317cda76b6e8e3#diff-912d11dfa52738be509f63e4ff1922a4 (And that commit
also includes documentation of the pins)


Sort of. But it does provide some hints as to how to utilize it to
improve control, If you have encoder feedback on axis axis then you
could feed the feedback.deriv pin with the velocity of that axis's
encoder. But from reading that, I fail to deduct a source for cmd.deriv.
I am envisioning a differential, for instance between current command
and previous command or maybe a sum2 with one input set for a gain of -1
and an rc lag from the command input to the other input giving a
differential output according to the charge across the cap. Since we
don't have a cap in hal components, we'ed have to use a low pass.  But I
quickly run out of imagination as to the rc time constant to synthesize.

just discussing the howto's would I think be educational for those of us
who never got the transcendental stuff in school 70+ years ago.

Help?

Thanks



Normally you would just connect the joint velocity pin to the PID command 
derivative





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 <http://geneslinuxbox.net:6309/gene>


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, andy pugh wrote:


Date: Wed, 4 Mar 2020 17:52:09 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Wed, 4 Mar 2020 at 17:26, Peter C. Wallace  wrote:



It was first added to 2.8 and them merged into 2.7 before the

2> 2.7.15 release AFAIK

I think that they were added in 2010:
https://github.com/LinuxCNC/linuxcnc/commit/44586b831e1ef5e826003190ab317cda76b6e8e3#diff-912d11dfa52738be509f63e4ff1922a4
(And that commit also includes documentation of the pins)


I meant the patch that made the command derivative behavior match the feedback 
derivative behavior (and the manual), that was quite recent.




--
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


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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, andy pugh wrote:


Date: Wed, 4 Mar 2020 17:20:02 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Wed, 4 Mar 2020 at 16:55, Peter C. Wallace  wrote:



> As for the docs, the generic 2.7 docs do NOT show any reference to
> pid.x.command-deriv
> Am I looking in the wrong place, or has it been removed?

It was added early in 2.8 and it works the same as feedback-deriv
(value calculated internally if unconnected)


I don't think that is right, as the problem we are seeing is with
2.7.15 systems.


It was first added to 2.8 and them merged into 2.7 before the
2.7.15 release AFAIK

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Wed, 4 Mar 2020, Jon Elson wrote:


Date: Wed, 04 Mar 2020 10:44:26 -0600
From: Jon Elson 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On 03/03/2020 09:22 PM, Peter C. Wallace wrote:


No, command-deriv is only used for the FF1 feedforward calculation

But, I DO use FF1 in practically all my configs, and it does seem to work.


It will work because if the command-deriv pin is not connected the derivative 
will be calculated internally


So, the problem is linking a signal to the command-deriv pin, but then NOT 
feeding it the correct derivative.  I can't see any way to fix this in PID.
The new 2.7.15 PID is not wrong, it just exposes an error in other code (the 
configs) that hadn't been right for

some time.


I guess without linking to command-deriv then PID calculates this internally 
by difference between this command and
the most recent command.  If you link a signal to command-deriv but do not 
provide the correct value, PID

would misbehave for sure.


Yes, you will get a 0 FF1 PID term



Not clear what to do in this case, but fixing the broken configs and the 
autoconfig program that creates these
seems important.  Documenting the problem is critical, and explaining what 
the user needs to do to

make his system run right.




As for the docs, the generic 2.7 docs do NOT show any reference to 
pid.x.command-deriv

Am I looking in the wrong place, or has it been removed?


It was added early in 2.8 and it works the same as feedback-deriv
(value calculated internally if unconnected)




Jon


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Tue, 3 Mar 2020, Gene Heskett wrote:


Date: Tue, 3 Mar 2020 23:21:54 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On Tuesday 03 March 2020 22:22:25 Peter C. Wallace wrote:


On Tue, 3 Mar 2020, Jon Elson wrote:

Date: Tue, 03 Mar 2020 20:54:55 -0600
From: Jon Elson 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On 03/03/2020 10:54 AM, andy pugh wrote:

On Tue, 3 Mar 2020 at 16:50, Jon Elson 

wrote:

Does anybody have a more specific case of how it is failing?


https://forum.linuxcnc.org/38-general-linuxcnc-questions/38367-2-7-
15?start=0


So, the pid command-deriv was not used in the past?  Geez, that
could explain a LOT of issues with
servo tuning before the change.

I use feedback-deriv in my servo systems, would a non-functioning
command-deriv make that not
work right?

Jon



No, command-deriv is only used for the FF1 feedforward calculation


Humm, Peter, none of my stuff uses that pid.n.command-deriv input now,
but I have used FF1 in my stepper configs, so how about some examples of
correct net useage statements to set that up right, once and for all?



If its working for you I would just leave the PIDs command derivative 
pin unconnected so its calculated internally.




Thanks Peter.

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 <http://geneslinuxbox.net:6309/gene>


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 2.7.15 PID Fix

[Peter C. Wallace]

On Tue, 3 Mar 2020, Jon Elson wrote:


Date: Tue, 03 Mar 2020 20:54:55 -0600
From: Jon Elson 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] 2.7.15 PID Fix

On 03/03/2020 10:54 AM, andy pugh wrote:

On Tue, 3 Mar 2020 at 16:50, Jon Elson  wrote:


Does anybody have a more specific case of how it is failing?

https://forum.linuxcnc.org/38-general-linuxcnc-questions/38367-2-7-15?start=0

So, the pid command-deriv was not used in the past?  Geez, that could explain 
a LOT of issues with

servo tuning before the change.

I use feedback-deriv in my servo systems, would a non-functioning 
command-deriv make that not

work right?

Jon



No, command-deriv is only used for the FF1 feedforward calculation




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] invalid config name, got 'HO?TMO?2', expected 'HOSTMOT2'

[Peter C. Wallace]

On Fri, 21 Feb 2020, Juergen Gnoss wrote:


Date: Fri, 21 Feb 2020 04:01:07 +
From: Juergen Gnoss 
Reply-To: EMC developers 
To: "emc-developers@lists.sourceforge.net"

Subject: [Emc-developers] invalid config name, got 'HO?TMO?2',
expected 'HOSTMOT2'



somebody any idea where that error comes from?

it is a fresh pncconf'ed configuration on a stretch machine

here the debug output :

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.0-pre0-1056-ge3548bc38
Machine configuration directory is '/home/jgnoss/linuxcnc/configs/bwoodrouter'
Machine configuration file is 'bwoodrouter.ini'
INIFILE=/home/jgnoss/linuxcnc/configs/bwoodrouter/bwoodrouter.ini
VERSION=1.1
PARAMETER_FILE=linuxcnc.var
TASK=milltask
HALUI=halui
DISPLAY=axis
COORDINATES=XYYZ
KINEMATICS=trivkins coordinates=XYYZ kinstype=BOTH
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
Found file(REL): ./bwoodrouter.hal
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script

trivkins: coordinates:XYYZ
  Joint 0 ==> Axis X
  Joint 1 ==> Axis Y
  Joint 2 ==> Axis Y
  Joint 3 ==> Axis Z

hm2: loading Mesa HostMot2 driver version 0.15
hm2_pci: loading Mesa AnyIO HostMot2 driver version 0.7
hm2_pci: discovered 5i25 at :03:05.0
hm2/hm2_5i25.0: Low Level init 0.15
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
hm2/hm2_5i25.0: invalid config name, got 'HO?TMO?2', expected 'HOSTMOT2'
hm2_5i25.0: board fails HM2 registration
RTAPI_PCI: Unmapped 65536 bytes at 0x7f612f334000
Driver probe function failed!
hm2_pci: error registering PCI driver
hm2_pci: rtapi_app_main: Operation not permitted (-1)
./bwoodrouter.hal:9: waitpid failed /usr/bin/rtapi_app hm2_pci
./bwoodrouter.hal:9: /usr/bin/rtapi_app exited without becoming ready
./bwoodrouter.hal:9: insmod for hm2_pci failed, returned -1
1605
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime



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



My first guess would be dirty PCI slot

Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] New parallel port error message

[Peter C. Wallace]

On Tue, 7 Jan 2020, Jon Elson wrote:


Date: Tue, 07 Jan 2020 11:02:14 -0600
From: Jon Elson 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] New parallel port error message

Hello, all, merry Christmas and a happy new year!
I've got a user who downloaded the latest (looks like development head), 
shows on screen
as 2.9.0, and he's using a PCIe parallel port at d010.  He gets the following 
message both in the log file
and on the Axis screen.  53264 decimal = d010 hex.  The parallel port is 
TRULY there, as
the system communicates with my PWM controller over it.  So, the message is 
totally
spurious.  I have seen this on other systems but have just been ignoring it. 
The message
"Linux parallel port" is not present in my hal_ppmc.c driver, it comes from 
the code that
manages reserving the parallel ports.  I'm pretty sure this message does NOT 
come out
when using motherboard ports at 0x378.  We specify the port address in the 
loadrt command

line for the hal_ppmc driver.

Debug file information:
Note: Using POSIX realtime
PPMC: bus 0 epp_dir = 0
Linux parallel port @53264 not found
PPMC: bus 1 epp_dir = 0
PPMC: bus 2 epp_dir = 0
PPMC: checking EPP bus 0 at port D010

Thanks for any suggestions on how to get rid of this.

Jon



I think I have seen this when there is no Linux driver for the specific port 
chipset. I agree its spurious since the Linux driver is not neccesary (at least

for chips that are standard enough that they dont need special setup)



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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Stretch and its preempt-rt kernel

[Peter C. Wallace]

On Fri, 1 Nov 2019, Gene Heskett wrote:


Date: Fri, 1 Nov 2019 19:32:38 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: EMC Developers 
Subject: [Emc-developers] Stretch and its preempt-rt kernel

I'm loggng that eth0 has a possible GRO (whatever that is) infection, and
that tcp performance might be degraded.



Probably OK to just just turn off GRO in the driver via ethtool




from dmesg:

TCP: eth0: Driver has suspect GRO implementation, TCP performance may be
compromised.

Doing a net searh it seems to be a feature of the
Linux coyote 4.9.0-11-rt-amd64
kernel being used.

Scutllebut on the net says its not a show stopper, and can be fixed with
most any later build. Could this be updated?

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Mesaflash docs

[Peter C. Wallace]

On Fri, 9 Aug 2019, Gene Heskett wrote:


Date: Fri, 9 Aug 2019 12:44:05 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Mesaflash docs

On Friday 09 August 2019 11:21:20 andy pugh wrote:


Are there any online docs for Mesaflash?
(And am I right in thinking that it is installed by default now?)


Docs? Don't seem to be, At least there are no manpages for it on any of
my machines.

Some details seem to be lacking, like some sort of a rule that tells you
to use mesaflash3 under certain conditions.  Thats something I haven't
seen discussed in the mesa docs I do have for the boards I use, which is
not near all. And I think it should be. Manpages would be nice.

Cheers, Gene Heskett



You should always use the latest

https://github.com/jethornton/mesaflash


--
"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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Release Platforms

[Peter C. Wallace]

On Wed, 22 May 2019, Chris Morley wrote:


Date: Wed, 22 May 2019 18:20:11 +
From: Chris Morley 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Release Platforms


From: andy pugh 
Sent: May 22, 2019 12:31 PM
To: EMC developers
Subject: [Emc-developers] Release Platforms


We have a problem...



We need a 2.7 LiveCD that works.
We will need a 2.8 LiveCD that works.


Thanks for tackling this Andy.

I would not give up the option for RTAI lightly. (I saw some talk on IRC about 
removing RTAI from the make file to simplify it)
based on the forum lots of people start with/ use the parport. (so some how 
they are getting it to work or using old systems)
AFAIK the RT kernel doesn't give good enough latency for parports.



Preempt-RT _can_ have good enough latency for parallel ports but the hardware 
with good Preempt-RT latency is different from hardware with good RTAI latency


In general my experience is that faster CPUs often have better Preempt-RT 
latency (often better than RTAI) but slower ( often passively cooled) CPUs

are much worse on Preempt-RT


As far as RTAI goes, Has anyone tried Bari's suggestion of NTULINUX/RTAI?

https://github.com/NTULINUX/RTAI





Thinking further ahead: What OS and realtime system should we plan to
release 2.8 on?


I will mention we were given permission to respin Mint:
https://forums.linuxmint.com/viewtopic.php?f=18=272185=1489079#p1489079
I think Mint is far more user friendly then Debian

I wonder if machinekit has had success with using RTAI still?

Chris M

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] To-Do list

[Peter C. Wallace]

On Sun, 28 Apr 2019, andy pugh wrote:


Date: Sun, 28 Apr 2019 00:12:49 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] To-Do list

Which bugs on the tracker mean that 2.8 can't be released?



I think that the unwanted motion caused by ON_ABORT_COMMAND needs to
be fixed before release.
https://github.com/LinuxCNC/linuxcnc/issues/579

Any others? We have 21 pull requests and 105 bugs..

What else needs to be done?

Update ISO downloads to Stretch. (easy for preempt-rt, already done,
harder or RTAI)



There are a number of Rob Ellenbergs bugfixes for the TP
that I dont think have been merged
(someone on the forum just ran into one of the fixed bugs)

Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] Parameter update rate

[Peter C. Wallace]

On Sat, 27 Apr 2019, Marius Liebenberg wrote:


Date: Sat, 27 Apr 2019 16:54:47 +0200
From: Marius Liebenberg 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Parameter update rate

Thanks Andy

Just to make sure that I understand it correctly.

If I read the position or velocity at every servo loop at say 1ms, and my 
step rate is at 100khz, I must still work out the steps required between 
every position given at the loop rate.



The motion component provides position waypoints and current velocities every 
servo period. A step generator typically uses these to set the current 
velocity by using the requested velocity from motion and making small 
corrections in this velocity based on the difference in motions position 
waypoint and the actual stepgen position counter. This correction is needed 
because of small errors caused by LinuxCNC/stepgen timebase differences,

imprecise read and write times, and velocity setpoint granularity.

This correction can be done in the stepgen itself or in LinuxCNC (via PID or 
thr step driver)








On 4/27/2019 12:18 PM, andy pugh wrote:
On Sat, 27 Apr 2019 at 09:49, Marius Liebenberg  
wrote:



At what rate is the velocity or position parameters of the StepGen
updated? Is that rate constant?

It should be the servo thread rate, and constant.





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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] EtherCAT

[Peter C. Wallace]

On Wed, 27 Mar 2019, Chris Morley wrote:


Date: Wed, 27 Mar 2019 00:59:18 +
From: Chris Morley 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] EtherCAT

I think adding docs would be a fine idea.

Chris M



Docs and perhaps some sample hal/ini files...



From: andy pugh 
Sent: March 25, 2019 1:56 PM
To: EMC developers
Subject: [Emc-developers] EtherCAT

Whilst I think we have decided that it is not possible to distribute
an EtherCAT driver with LinuxCNC[1] it seems that some users are using
it extensively and successfully.

Which leads me to wonder if we should include a section in the
documentation about its use and where to download the enabling
software?

[1] Though where the license-break is is not clear:
Sascha's HAL driver is GPLv2:
https://github.com/sittner/linuxcnc-ethercat but I seem to recall that
actual use of EtherCAT involves an implied compliance with the
Beckhoff terms.
There is a summary here in an old machinekit discussion:
https://groups.google.com/forum/#!search/machinekit$20beckhoff/machinekit/yxQxqNbMvtc/UsaYVfAarCsJ

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916


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

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

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

Re: [Emc-developers] probably an un-answerable question

[Peter C. Wallace]

On Wed, 20 Mar 2019, Gene Heskett wrote:


Date: Wed, 20 Mar 2019 21:03:43 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] probably an un-answerable question

The little 8 oz plastic coke bottle can handle how many psi?

I'm thinking of poking 2 holes in the lid, one to let the pressure in
from the air valve, and one to get the coolant back out of the bottle.

The pressure could easily be 30+ psi in the coke bottle, am I designing a
hand grenade?

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)
Genes Web page 



You could always use a SodaStream bottle if you need more margin
(though they are larger)

https://www.youtube.com/watch?v=HjcyLPN4bZk






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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] removal of gedit as default editor

[Peter C. Wallace]

On Wed, 20 Mar 2019, Moses McKnight wrote:


Date: Wed, 20 Mar 2019 13:45:42 -0500
From: Moses McKnight 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] removal of gedit as default editor

On 3/20/19 1:01 PM, Gene Heskett wrote:

Now we know of two victims. Stuart and I. :(


Well, that would explain why it didn't get removed from distributions!  2 
glitches out of 2 million installs (<-random number), and it is the official 
text editor for Gnome.


I suspect a third person probably had a glitch, and he fixed it - which is 
why no one else has ever had a glitch with it. ;-)


I've used it for many years myself and use it pretty much daily still and 
have never had it corrupt anything.


Moses




I use gedit frequently, and at one time (maybe 2 years ago) I had it corrupt a 
file (multiple pastes scattered throughout the file), but since then I have 
not had a re-occurance, I do suspect that this bug (which might be WM 
dependent) has been fixed




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

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

[Peter C. Wallace]

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

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

[Peter C. Wallace]

On Wed, 6 Mar 2019, Alan Condit wrote:


Date: Wed, 6 Mar 2019 14:33:08 -0800
From: Alan Condit 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Emc-developers Digest, Vol 155, Issue 12

Hey Peter,

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

IRC handle for Robert Schoftner



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?

[Peter C. Wallace]

On Wed, 6 Mar 2019, Gene Heskett wrote:


Date: Wed, 6 Mar 2019 11:29:29 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] future of rpi?

Huge snip about rpi updates destroying that install:

I think, given the resources at hand, that I'll be quicker to a working
machine by reburning the 7i90HD with a parport interface, and finding a
way to hang the old dell I use for mesa-card programming on the 1.5"
post holding up what's there now and using a 26 pin cable maybe 2 feet
long to reach into the interface box and drive the 7i90HD. That post is
loaded now, so I'll have to fab some mounting brackets etc.  Not to
mention clearing out behind the lathe so I can get back there to work.
Open floor space is soon occupied, by paint buckets, pieces removed from
the lathe by the conversion and tools tossed down because I'm too lazy
to put them away properly.

In retrospect, keeping that Jessie install up to date was a mistake.
Keeping the rest of the wheezy/intel installs uptodate has been good,
but one tends to forget that intel is everywhere, so updates are subject
to thousands of eyeballs, while the pi is 100% proprietary and they can
do as they please, and apparently have. I'd buy another D525MW mobo, but
I've no place to put it out of the flying swarf unless someone has found
a suitable box???.

Thats why I originally bought the whole shoebox from ARK when I bought
the two of those I do have. Put them and the drivers on high shelves and
out of the flying swarf. Thats worked well.

In fact, this 7i90HD has been noise damaged and I've programmed around
it, so this is a good excuse as I'll have to order another.  And then
I'll have all good stepgens again in case I want to add some more
gingerbread.

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



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] 7i76 vs spinout signal

[Peter C. Wallace]

On Thu, 7 Feb 2019, Gene Heskett wrote:


Date: Thu, 7 Feb 2019 19:56:20 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Thursday 07 February 2019 19:41:20 Peter C. Wallace wrote:


Yes its fixable  just needs a TLP127 OPTO and careful work with a SMT
hot air gun...


And if you do it? How much?  I have the hot air tools, but the hands at
84 are getting a little shaky for that sort of work.  As I am learning
in doing this project.


Just send it back And I'll fix it




Thanks Peter.


feed 5 volts regulated to spindir+. wire internal to the interface
box Feed interface boxes +12 unswitched power over the cable to +12
volt Feed regulated 12 volts to spinena+,  Third wire
Feed spinena- to servo enable on pin 5.
Find pwmgen-01.pulse to PWM + on servo pin-1


Feed a signal from the Sainsmart's pwm-1-output to the pwm+ at
pin1 on the servo is the 5th wire and the connector is full. Once
thats done, take 3/8" off the bottom of the swarf shield over the
x-home-switch, which will allow that to come back over the top of
the y motor, giving me back a sorely needed additional inch or
more of y motion. The table was coming forward but this swarf
shield was too long and was hitting the motor mount.  If I clear
that, I gain nearly 1.5" of y motion. When I put that bellows
cover on, I was far more concerned with keeping swarf out of the y
screw when I built it 4 years ago.

Now, a question for Jon:

Normally that 12 volts to the logic on pin 6 will be present
anytime the interfaces line cord is plugged in, and which I intend
eventually to plug into the power strip that feeds the rest of the
motor power box. So it will come on with all the stepper drivers,
but spindle power is soft started by enabling the machine from F2,
takes 3 seconds to get full power.  And I don't trip a 30 amp
breaker charging the supplies caps.

But is it safe to apply the high voltage motor power to the
pwm-servo amp IF for some reason the interface is powerless and
its 12 volt supply is off. This will put full motor power at
pins-1-2, with no logic power on pin 6.

Is that safe, or will it let some smoke out and kill all the local
kittens? I could rig a relay, or better yet, move the SSR +
terminals to the 12 volt supply, better yet disable that in hal if
the 12 volts isn't there by changing the sserial com mode so it
will send an a/d output back to lcnc.  Thats slower of course but
I'll check it out.

Thanks Jon.


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


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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



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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Thu, 7 Feb 2019, Gene Heskett wrote:


Date: Thu, 7 Feb 2019 19:33:46 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Thursday 07 February 2019 15:49:09 Gene Heskett wrote:


On Thursday 07 February 2019 13:07:53 Gene Heskett wrote:

On Tuesday 05 February 2019 21:49:21 Gene Heskett wrote:

So ATM I have a reserved input for the probe, and the steppers to
wire step-dir sigs to, and I think put the probe on a 5 pin plug
thats not busy.

Then I should be ready to smoke test it by late tomorrow.. So far
I've not given the motors any power, safer that way. But I had to
redo the mechanics of the x home switch, buried under a bunch of
covers, its probably still not mechanically right, but I'll need
stepper power and a good light to see what needs to be done.


Got that all done, but wore out a knee, its about due for another
acid shot, giving me he!! this morning yet.  Steppers all done, as
are home switches.


Correction, to clarify what I am doing to me when I take a copy to the
machine to build it.

I believe I've figured out how to squeeze the pwmservo's controls
into 1, 5 pin plug.

Connecting a ground to pin2 and pin4 on the servo hooks up a - for the
optos for pwm and dir. 1 wire. The shields in a two pair cable, use
pin 3 in the GS12-5 connector.
Feed regulated 5 volts to spindir+ right on the 7i76. no cable wire
Feed spindir- to servo pin 3, direction+.  2nd cable wire, will pullup
servo direction line.


To PCW:

But I got shaky making up that cable and connector and inadvertantly made
a solder blob short between spindir- and ground, with 5.11 volts on
spindir+.  And spindir- isn't coming on even with the short removed now.
FWIW, all 5 of the contacts in this plug are in about a 5.5mm circle.
Next panel I'll use the GS16-5 plug, bigger and far easier for this old
man to work with.



Yeah you can definately fry the OPTO transistors by driving into shorted load




I've fixed the short, but may have toasted that driver chip. If it was
ptc protected, does it take a full everything off including the computer
to reset it, and how much cooldown time. Its had power but has not come
back in around 30 minutes. No heat either.

So sock it to me Peter. If its toes up for good, I can put the 2nd card
in, in which case can you fix this one?


Yes its fixable  just needs a TLP127 OPTO and careful work with a SMT hot air 
gun...




Thanks Peter.


feed 5 volts regulated to spindir+. wire internal to the interface box
Feed interface boxes +12 unswitched power over the cable to +12 volt
Feed regulated 12 volts to spinena+,  Third wire
Feed spinena- to servo enable on pin 5.
Find pwmgen-01.pulse to PWM + on servo pin-1


Feed a signal from the Sainsmart's pwm-1-output to the pwm+ at pin1
on the servo is the 5th wire and the connector is full. Once thats
done, take 3/8" off the bottom of the swarf shield over the
x-home-switch, which will allow that to come back over the top of
the y motor, giving me back a sorely needed additional inch or more
of y motion. The table was coming forward but this swarf shield was
too long and was hitting the motor mount.  If I clear that, I gain
nearly 1.5" of y motion. When I put that bellows cover on, I was far
more concerned with keeping swarf out of the y screw when I built it
4 years ago.

Now, a question for Jon:

Normally that 12 volts to the logic on pin 6 will be present anytime
the interfaces line cord is plugged in, and which I intend
eventually to plug into the power strip that feeds the rest of the
motor power box. So it will come on with all the stepper drivers,
but spindle power is soft started by enabling the machine from F2,
takes 3 seconds to get full power.  And I don't trip a 30 amp
breaker charging the supplies caps.

But is it safe to apply the high voltage motor power to the
pwm-servo amp IF for some reason the interface is powerless and its
12 volt supply is off. This will put full motor power at pins-1-2,
with no logic power on pin 6.

Is that safe, or will it let some smoke out and kill all the local
kittens? I could rig a relay, or better yet, move the SSR +
terminals to the 12 volt supply, better yet disable that in hal if
the 12 volts isn't there by changing the sserial com mode so it will
send an a/d output back to lcnc.  Thats slower of course but I'll
check it out.

Thanks Jon.


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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Mon, 4 Feb 2019, Gene Heskett wrote:


Date: Mon, 4 Feb 2019 05:13:08 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Sunday 03 February 2019 20:03:28 Peter C. Wallace wrote:


On Sun, 3 Feb 2019, Gene Heskett wrote:

Date: Sun, 3 Feb 2019 19:56:53 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Sunday 03 February 2019 09:30:46 Peter C. Wallace wrote:

On Sun, 3 Feb 2019, Gene Heskett wrote:


getting TLDR, clipped most of whats been solved


The 7I76 spindle ENA and DIR outputs are independent of the analog
value of spinout, (though the analog out is forced to 0 if spinena
is false) is it possible you have a wiring error?


This is solved and it looks like I can excise that other stuff from
the hal file.

Now, re a lack of response at the actual outputs 15 and 14.

I did a setp to set invert true, made them come on when they should
have been off so I setp them to false, and now they are working as
desired.


I dont think thats the case, I suspect you misdiagnosed the initial
test


While thats always a possibility, but its a test reading I did multiple
times for both conditions, and until I added the
setp output-invert true,
which made it backwards, so I setp'd it false and it works as expected.



If thats really case, I think you may have a thread order or other error in 
your hal file.


Is certainly not a known problem with 7I76 outputs, and I just verified here 
that they work as expected.




ATM its the middle of the night and I'm trying to see if I have all 4
stepgens ready to hook up later today, and I find I cannot see the
actual steps with a halscope any place.  So I'll have to scope probe the
7i76 stepgen pulse outputs.  Is this correct? Or is there a way to see
them on a halscope pin when there is no base thread? I can't find an
output that shows them, Probably too short for halscope running on
srevo-thread to see. I can see the dir changes at the corresponding
gpio.in, so I assume they are working. I'll try to get that all hooked
up today, leaving the home switches and encoder to sort tomorrow.  And
that should get that mill 100% usable again. Leaving me plotting how to
make a tool changer for it.  And searching for an endoscope camera that
actually works.

On another front, I have the alignment kit working well on the 6040
already. Theoretically, just copying that code to this machine should
handle that. easy-peasy on the 6040 as the workpiece is usually mounted
on a spoil board and therefore insulated, so it could be made to use a
G38.2 to detect the angular error. Aligning the machine to the workpiece
rather than the other way around.


You can allways temporarily set the step mode to quadrature
you can always get about 50% state read on a undersample
(the likely hood of catchinh a 1 usec pulse at 1 KHz is only 1 in a 1000)




Thanks Peter.


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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



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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Sun, 3 Feb 2019, Gene Heskett wrote:


Date: Sun, 3 Feb 2019 19:56:53 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Sunday 03 February 2019 09:30:46 Peter C. Wallace wrote:


On Sun, 3 Feb 2019, Gene Heskett wrote:


getting TLDR, clipped most of whats been solved


The 7I76 spindle ENA and DIR outputs are independent of the analog
value of spinout, (though the analog out is forced to 0 if spinena is
false) is it possible you have a wiring error?

This is solved and it looks like I can excise that other stuff from the
hal file.

Now, re a lack of response at the actual outputs 15 and 14.

I did a setp to set invert true, made them come on when they should have
been off so I setp them to false, and now they are working as desired.


I dont think thats the case, I suspect you misdiagnosed the initial test


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

the nuts on those connectors which are below the boards in this box.

Now in the next step of wiring this up I have a pair of 40 amp SSR's, 
with 5.11+ on both + terminals of the SSR's, and am using 
hm2_5i25.0.7i76.0.0.outputs 15 and 14 with the idea that turning them on 
will ground the -terminals, enabling the SSR's in sequence, when the 
first one is enabled, power is applied to the stack of toroids thru a 50 
ohm 200 watt resistor the start chargeing the filter caps, 3 second 
later an identical signal is sent to hm2_5i25.0.7i76.0.0.output14 which 
bypasses the 50 ohm resistor, enabling the spindle psu at full power.


I can see, with a halmeter that the signal is sent to those output pins.

But they aren't turning on to sink the - pins of the SSR's.  They 
regardless of the halmeter state, stubbornly sitting at 4.66+ which 
would be about what I'd expect to see when I measure to ground/common 
with a 10 megohm input DVM from the - terminals of the SSR controls. Not 
enough current flowing thru the meter to tickle the SSR's of course. I 
am wired to the last and next to last at the upper end of TB5 which the 
docs say is output15 and output14. Field power on the orange connector 
is 12.2 volts positive on pin 1, and negatives are wired common between 
pin 8 of the orange connector and pin 24 of the 4 pin header to its 
left.





Another common issue can be that you are not using the field power common for 
the load common (note that the field I/O is galvanically isolated from logic 
power so the load power common must connect to the field power (orange 
connector) common



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Sun, 3 Feb 2019, Gene Heskett wrote:


Date: Sun, 3 Feb 2019 14:34:13 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Sunday 03 February 2019 09:30:46 Peter C. Wallace wrote:



On Sun, 3 Feb 2019, Gene Heskett wrote:
> Date: Sun, 3 Feb 2019 07:16:13 -0500
> From: Gene Heskett 
> Reply-To: EMC developers 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] 7i76 vs spinout signal
>
> On Sunday 03 February 2019 01:19:26 Peter C. Wallace wrote:
>
> On Sat, 2 Feb 2019, Gene Heskett wrote:
> > Date: Sat, 2 Feb 2019 21:46:24 -0500
> > From: Gene Heskett 
> > Reply-To: EMC developers 
> > To: emc-developers@lists.sourceforge.net
> > Subject: Re: [Emc-developers] 7i76 vs spinout signal
> >
> > On Saturday 02 February 2019 19:51:18 Peter C. Wallace wrote:
> >
> > On Sat, 2 Feb 2019, Gene Heskett wrote:
> > > Date: Sat, 2 Feb 2019 19:01:59 -0500
> > > From: Gene Heskett 
> > > Reply-To: EMC developers 
> > > To: emc-developers@lists.sourceforge.net
> > > Subject: Re: [Emc-developers] 7i76 vs spinout signal
> > >
> > > On Saturday 02 February 2019 16:00:04 Andy Pugh wrote:
> > > > On 2 Feb 2019, at 18:13, Gene Heskett 
> > > > wrote:
> > > >
> > > > But whats the range of spindle speed requests that are valid
> > > > in that case.
> > >
> > > Approx -1.8 x 10^308 to  +1.8 x 10^308
> > >
> > > Because its a double precision floating point.
> > >
> > > Are you reading the 7i76 manual or just the LinuxCNC docs?
> >
> > The 7i76 manual lacks anything like such an explanation for the
> > spindle functions. Or has it been expanded and corrected?, I've
> > had the doc file I am looking at for about 3 months now.
> >
> > Thanks Andy.
>
> I just read it again, top to bottom and back up. None of this stuff
> is in it, nor is there any reference to reading the manpage for
> sserial.
>
> > The sserial man page has some info about the 7i76 pins
>
> So it does, but haveing no reference to it in the doc, I hadn't read
> it until now. It also states theres a high likelyhood of its being
> permanently out of date.  And it makes zero mention that ENA and DIR
> appear to be activated ONLY when when spinout has valid non-zero
> data. That might work for a vfd but not for a pwm-servo such as Jon
> sells. The way its worded, ENA and DIR appear to be straight thru
> from input to output isolated controls, which would make them 100%
> useful. But because they aren't activated until spinout has valid
> non-zero data, the ENA is of zero use to me. That amp must be
> enabled, then pulsed to charge the gates properly before the data
> from the pid.out arrives at the pwmgen.1.value pin to start its
> generation of pulses. I do have a method worked out that should
> work, using the otherwise mounted for its looks, relay on the
> SainSmart BoB. Driven by p2 of the 5i25 using a special bitfile
> Peter sent me which puts a 2nd pwmgen on the P2 connector since the
> first one goes to /dev/null in the 7i76d. I may be able to get that
> wired up tomorrow, but I am making all this hookup hardware as I go.
> From a 150 foot spool of wire, and a bag of GS12-5 connectors.
> Darned near too small for these getting a little shaky old hands.
>
>
>
>
> Thats not quite true, The 7I76 DIR output is a completely
> independent output bit and ENA must be present for the analog output
> to work, that is analog out is dependent on ENA but not the other
> way around.

I did not find that in my testing, Peter. Neither ENA- was pulled up
to the +12 volts on ENA+, nor was DIR- pulled up to the +5 volts on
DIR+, until I gave it a non-zero spinout. In my testing, no power was
applied to tb4,1-3 because the intent is to use the 2nd pwmgen as the
input to jon's servo amp in this instant build. I will use it with the
vfd in the 6040 build that I bought the 2nd 7i76d for. So I was forced
to use the relay on a sainsmart bob to switch the ena to the pwm-servo
amp and use a timedelay module to delay everything else until the
relay was solidly closed.

Is there some other magic I missed?  Humm, maybe, I had not learned
about the params that needed set according to "man 9 sserial" until
yesterday. IMO, this should have been mentioned in the downloadable
doc for the 7i76 but is not. They now are being set, so I'll retest
and advise today.

Those aren't accessible to a halmeter, so I have to use a dvm (or a
scope) to verify. And I was reading  a wandering 60 millivolts to
ground at those terminals.

Thanks Peter.


The 7I76 spindle

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Sun, 3 Feb 2019, Gene Heskett wrote:


Date: Sun, 3 Feb 2019 07:16:13 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Sunday 03 February 2019 01:19:26 Peter C. Wallace wrote:



On Sat, 2 Feb 2019, Gene Heskett wrote:
> Date: Sat, 2 Feb 2019 21:46:24 -0500
> From: Gene Heskett 
> Reply-To: EMC developers 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] 7i76 vs spinout signal
>
> On Saturday 02 February 2019 19:51:18 Peter C. Wallace wrote:
>
> On Sat, 2 Feb 2019, Gene Heskett wrote:
> > Date: Sat, 2 Feb 2019 19:01:59 -0500
> > From: Gene Heskett 
> > Reply-To: EMC developers 
> > To: emc-developers@lists.sourceforge.net
> > Subject: Re: [Emc-developers] 7i76 vs spinout signal
> >
> > On Saturday 02 February 2019 16:00:04 Andy Pugh wrote:
> > > On 2 Feb 2019, at 18:13, Gene Heskett 
> > > wrote:
> > >
> > > But whats the range of spindle speed requests that are valid in
> > > that case.
> >
> > Approx -1.8 x 10^308 to  +1.8 x 10^308
> >
> > Because its a double precision floating point.
> >
> > Are you reading the 7i76 manual or just the LinuxCNC docs?
>
> The 7i76 manual lacks anything like such an explanation for the
> spindle functions. Or has it been expanded and corrected?, I've had
> the doc file I am looking at for about 3 months now.
>
> Thanks Andy.

I just read it again, top to bottom and back up. None of this stuff is
in it, nor is there any reference to reading the manpage for sserial.

> The sserial man page has some info about the 7i76 pins

So it does, but haveing no reference to it in the doc, I hadn't read
it until now. It also states theres a high likelyhood of its being
permanently out of date.  And it makes zero mention that ENA and DIR
appear to be activated ONLY when when spinout has valid non-zero data.
That might work for a vfd but not for a pwm-servo such as Jon sells.
The way its worded, ENA and DIR appear to be straight thru from input
to output isolated controls, which would make them 100% useful. But
because they aren't activated until spinout has valid non-zero data,
the ENA is of zero use to me. That amp must be enabled, then pulsed to
charge the gates properly before the data from the pid.out arrives at
the pwmgen.1.value pin to start its generation of pulses. I do have a
method worked out that should work, using the otherwise mounted for
its looks, relay on the SainSmart BoB. Driven by p2 of the 5i25 using
a special bitfile Peter sent me which puts a 2nd pwmgen on the P2
connector since the first one goes to /dev/null in the 7i76d. I may be
able to get that wired up tomorrow, but I am making all this hookup
hardware as I go. From a 150 foot spool of wire, and a bag of GS12-5
connectors. Darned near too small for these getting a little shaky old
hands.




Thats not quite true, The 7I76 DIR output is a completely independent
output bit and ENA must be present for the analog output to work, that
is analog out is dependent on ENA but not the other way around.

I did not find that in my testing, Peter. Neither ENA- was pulled up to 
the +12 volts on ENA+, nor was DIR- pulled up to the +5 volts on DIR+, 
until I gave it a non-zero spinout. In my testing, no power was applied 
to tb4,1-3 because the intent is to use the 2nd pwmgen as the input to 
jon's servo amp in this instant build. I will use it with the vfd in the 
6040 build that I bought the 2nd 7i76d for. So I was forced to use the 
relay on a sainsmart bob to switch the ena to the pwm-servo amp and use 
a timedelay module to delay everything else until the relay was solidly 
closed.


Is there some other magic I missed?  Humm, maybe, I had not learned about 
the params that needed set according to "man 9 sserial" until yesterday. 
IMO, this should have been mentioned in the downloadable doc for the 
7i76 but is not. They now are being set, so I'll retest and advise 
today.


Those aren't accessible to a halmeter, so I have to use a dvm (or a 
scope) to verify. And I was reading  a wandering 60 millivolts to ground 
at those terminals.


Thanks Peter.


The 7I76 spindle ENA and DIR outputs are independent of the analog value
of spinout, (though the analog out is forced to 0 if spinena is false)
is it possible you have a wiring error?


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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-devel

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Sat, 2 Feb 2019, Gene Heskett wrote:


Date: Sat, 2 Feb 2019 21:46:24 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Saturday 02 February 2019 19:51:18 Peter C. Wallace wrote:



On Sat, 2 Feb 2019, Gene Heskett wrote:
> Date: Sat, 2 Feb 2019 19:01:59 -0500
> From: Gene Heskett 
> Reply-To: EMC developers 
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] 7i76 vs spinout signal
>
> On Saturday 02 February 2019 16:00:04 Andy Pugh wrote:
> > On 2 Feb 2019, at 18:13, Gene Heskett 
> > wrote:
> >
> > But whats the range of spindle speed requests that are valid in
> > that case.
>
> Approx -1.8 x 10^308 to  +1.8 x 10^308
>
> Because its a double precision floating point.
>
> Are you reading the 7i76 manual or just the LinuxCNC docs?

The 7i76 manual lacks anything like such an explanation for the
spindle functions. Or has it been expanded and corrected?, I've had
the doc file I am looking at for about 3 months now.

Thanks Andy.

I just read it again, top to bottom and back up. None of this stuff is in 
it, nor is there any reference to reading the manpage for sserial.


The sserial man page has some info about the 7i76 pins


So it does, but haveing no reference to it in the doc, I hadn't read it 
until now. It also states theres a high likelyhood of its being 
permanently out of date.  And it makes zero mention that ENA and DIR 
appear to be activated ONLY when when spinout has valid non-zero data. 
That might work for a vfd but not for a pwm-servo such as Jon sells. The 
way its worded, ENA and DIR appear to be straight thru from input to 
output isolated controls, which would make them 100% useful. But because 
they aren't activated until spinout has valid non-zero data, the ENA is 
of zero use to me. That amp must be enabled, then pulsed to charge the 
gates properly before the data from the pid.out arrives at the 
pwmgen.1.value pin to start its generation of pulses. I do have a method 
worked out that should work, using the otherwise mounted for its looks, 
relay on the SainSmart BoB. Driven by p2 of the 5i25 using a special 
bitfile Peter sent me which puts a 2nd pwmgen on the P2 connector since 
the first one goes to /dev/null in the 7i76d. I may be able to get that 
wired up tomorrow, but I am making all this hookup hardware as I go. 
From a 150 foot spool of wire, and a bag of GS12-5 connectors. Darned 
near too small for these getting a little shaky old hands.





Thats not quite true, The 7I76 DIR output is a completely independent output 
bit and ENA must be present for the analog output to work, that is analog out 
is dependent on ENA but not the other way around.


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Sat, 2 Feb 2019, Gene Heskett wrote:


Date: Sat, 2 Feb 2019 19:01:59 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 7i76 vs spinout signal

On Saturday 02 February 2019 16:00:04 Andy Pugh wrote:



> On 2 Feb 2019, at 18:13, Gene Heskett  wrote:
>
> But whats the range of spindle speed requests that are valid in that
> case.

Approx -1.8 x 10^308 to  +1.8 x 10^308

Because it??s a double precision floating point.

Are you reading the 7i76 manual or just the LinuxCNC docs?

The 7i76 manual lacks anything like such an explanation for the spindle 
functions. Or has it been expanded and corrected?, I've had the doc file 
I am looking at for about 3 months now.


Thanks Andy.


The sserial man page has some info about the 7i76 pins






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



Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 7i76 vs spinout signal

[Peter C. Wallace]

On Sat, 2 Feb 2019, Gene Heskett wrote:


Date: Sat, 2 Feb 2019 07:37:11 -0500
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers 
Subject: [Emc-developers] 7i76 vs spinout signal

Can someone please explain to me, who is used to using a spinx1 for the
pwmgen output to analog voltage conversion, just how in tuncket the 7i76
works? I just now found out, when I tried to redirect a 5i25 pwmgen
output pin and found from the error  msg as it died, that
hm2_5i25.0.7i76.spinout is a float input!

In Other Words, pwmgen.0. in the 5i25 is driveing /dev/null.  So I fed
the hm2_5i25.0.pwmgen.0.value to hm2_5i25.0.7i76.spinout and can now
read it there with a halmeter.  But I've no clue what sort of a float it
wants to use the full voltage range of tb4's spindle- to tb4's spindle+
at tb4's spindle-out.

The document on the 7i76 seems to be totally mute on this. Can some who
knows please explain?

To say I am bumfuzzled at this revelation is putting it mildly if this
does indeed bring the ENA and DIR outputs on tb4 to life, which are not
responding with spinout at 0.. I'll have to recalibrate scales
and gains at several locations in nearly a 800 LOC hal file.

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)
Genes Web page 



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




The 7I76 spindle output should not be too different from a PWM setup
There are three pins related to spindle control

7i76.x.x.spindir
7i76.x.x.spinena
7i76.x.x.spinout

and 5 parameters

7i76.x.x.spindir-invert
7i76.x.x.spinena-invert
7i76.x.x.spinout-maxlim
7i76.x.x.spinout-minlim
7i76.x.x.spinout-scalemax


Typically the maxlim and scalemax parameters are set to the maximum spindle 
RPM, and the minlim parameter is set to 0. This scales the analog voltage so 
full scale RPM is full scale voltage (100% of SPIN+)


The 7I76 output is unipolar so normally its linked to motions spindle speed 
speed-out-abs pin


Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] new member and a lot of questions...

[Peter C. Wallace]

On Thu, 31 Jan 2019, wi...@erste.de wrote:


Date: Thu, 31 Jan 2019 13:07:22 +0100
From: wi...@erste.de
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] new member and a lot of questions...

Am 31.01.19 um 11:55 schrieb andy pugh:

Does RTAI allow Ethernet hardware access?


here is a realtime-eth-projekt:

http://rtnet.org/



but latest update is nearly 6 yaers old: 9 May 2013



RTnet was going to be folded into Xenomai using RTDM but very sadly the guy 
working on this (Gilles Chanteperdrix) died unexpectedly in 2016. I think ist 
is abandoned at this point.


We (Mesa) had originally used RTnet+RTAI for our Ethernet connected motion 
devices but the lack of modern MAC support led us to try Preempt-RT and

userland real time and it proved adequate for servo thread rate realtime
and keeps getting better as Preempt-RT improves.




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] My g0704 is unusable after the last week or so's updates

[Peter C. Wallace]

Greetings all;

I went out in my half blind condition, found a bar of cold roll to
make a different x-home switch activator for the g0704. Fired up
LCNC which came up normal, but was not moveable for homing or by
jogging without an instant following error. Putting a halmeter on
the joint error, it was reported to be in the #-16 to #-18 range.
Danged close IOW.

My following error setting have been min=0.0005 and ferror 0.001 for
many months.  Without any problems.

Tonight I find I can't jog at above .05 ipm without resetting them
to min= at least .0025", and ferror at least .005", or nominally 5
times the working errors of around a month ago when I was making all
those tap hats. Once the error settings exceed the backlash, it will
move at close to 100 ipm in either direction of any axis.

So it seems related to BACKLASH, which worst cases are
GO704fast.ini:BACKLASH  = 0.00190 (x)
GO704fast.ini:BACKLASH  = 0.000950(y)
GO704fast.ini:BACKLASH  = 0.00320 (z)

Has anything been changed in that area of the code recently?

Thanks everybody for clues to check next.

--
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 


The PID component changed a few months ago, so if your stepgen uses
the PID component and you updated the LinuxCNC version recently, you
may need to make some minor changes in the hal file (disconnecting the
pid.N.command-deriv pins)


Done, Peter but not tested as motor power is hand controlled on that
machine. As it is on the other 2, only the pi can power things up via an
ssh login.

Thanks Peter. Is there a new man page? I think I may be looking at the
old one.



The PID manual page is correct

(it always was, its the PID component that has been patched to match the 
documented behaviour)






--
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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] My g0704 is unusable after the last week or so's updates

[Peter C. Wallace]

On Sat, 20 Oct 2018, Gene Heskett wrote:


Date: Sat, 20 Oct 2018 21:50:36 -0400
From: Gene Heskett 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] My g0704 is unusable after the last week or so's
updates

Greetings all;

I went out in my half blind condition, found a bar of cold roll to make a
different x-home switch activator for the g0704. Fired up LCNC which
came up normal, but was not moveable for homing or by jogging without an
instant following error. Putting a halmeter on the joint error, it was
reported to be in the #-16 to #-18 range. Danged close IOW.

My following error setting have been min=0.0005 and ferror 0.001 for many
months.  Without any problems.

Tonight I find I can't jog at above .05 ipm without resetting them to
min= at least .0025", and ferror at least .005", or nominally 5 times
the working errors of around a month ago when I was making all those tap
hats. Once the error settings exceed the backlash, it will move at close
to 100 ipm in either direction of any axis.

So it seems related to BACKLASH, which worst cases are
GO704fast.ini:BACKLASH  = 0.00190 (x)
GO704fast.ini:BACKLASH  = 0.000950(y)
GO704fast.ini:BACKLASH  = 0.00320 (z)

Has anything been changed in that area of the code recently?

Thanks everybody for clues to check next.

--
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 




The PID component changed a few months ago, so if your stepgen uses the PID 
component and you updated the LinuxCNC version recently, you may need to make 
some minor changes in the hal file (disconnecting the pid.N.command-deriv 
pins)





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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

Re: [Emc-developers] Removing myself from the LinuxCNC decision-making process

[Peter C. Wallace]

On Mon, 27 Aug 2018, Jeff Epler wrote:


Date: Mon, 27 Aug 2018 17:41:43 -0500
From: Jeff Epler 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] Removing myself from the LinuxCNC decision-making
process

Hi all.

I first became involved with LinuxCNC in 2004, and it remains the Free
Software project to which I've made the largest contribution.  However,
I haven't been very involved with the development or use of LinuxCNC for
years---in fact, looking back at my blog, it has been almost 9 years
since I last did anything on my little CNC router worth mentioning.

During my time as a more active developer, I often positioned myself as
a gatekeeper.  At the time I believed that by exercising control over
what went in to LinuxCNC, I was preserving the software from harm.  More
important than whether any of those individual decisions was right or
wrong, I now worry that I have contributed to a bad culture in LinuxCNC
that drove away contributors.

It has been said that the Internet is founded on "rough consensus and
running code".  Today, I think that LinuxCNC could benefit from more of
this attitude and less of my "gate-keeping" style of dealing with
contributions.

For these reasons, I have decided that it's time to make it official:
I'm taking myself out of the loop of LinuxCNC, particularly and most
importantly as it comes to making decisions about pull requests.

As far as any administrative privileges I have (github, website, IRC,
sourceforge(!), etc): I'll turn in my keys to any of those on request,
as long as that leaves at least two people who will keep that service
going to the benefit of LinuxCNC developers and users.  In the meantime,
I don't mind keeping the forum software and its OS up to date as I have
been doing.

A number of you are really good friends.  I'd like to keep it that way.
I plan to keep hanging out in #linuxcnc-devel and I'll try to provide my
"wisdom" if it's requested.

Please use the remainder of this thread to reminisce about the good
times.  For instance, I fondly remember two events in particular from
the CNC Workshops I attended in Galesburg:

1) We're all sitting at the pizza place, and Jon Elson and John Kasunich
are both trying to out-do the other with stories about mishaps with
power electronics.  I've still got nothing on even the tamest of their
tales.

2) While running the Mazak, I discover that hitting alt-tab makes rtapi
freeze up for a few milliseconds while the screen redraws, leading to an
audible "BAM!" from the mill.  Instead of exercising common sense and
not doing *that* again, I held down alt-tab to make it go "BAM BAM BAM
BAM" until someone ran up to hit estop.  (the fix was replacing the
video card, I think I recall)  You shouldn't leave a newbie in charge of
a big machine like that, even for a moment!

I wish you all, and the project itself, the best.

Jeff

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



Thank you for your long support and guidance of the LinuxCNC project.

I do hope your guidance and in depth knowledge on programming remains 
available.


Its easy to second-guess the right choices between conservative and
wide open development policies but I do think the LinuxCNC benefited greatly 
with your choices. I can understand the general difficulty of getting new 
developers:


Long hours

Little appreciation

0 pay

complex problems

Thanks from doing this as long as you did!



Peter Wallace
Mesa Electronics

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

Re: [Emc-developers] Absolute resolvers

[Peter C. Wallace]

On Thu, 5 Jul 2018, andy pugh wrote:


Date: Thu, 5 Jul 2018 20:18:37 +0100
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: [Emc-developers] Absolute resolvers

Using the position.txt file and a tweak to the Mesa resolver driver I
have had good results making my lathe work as if it has absolute
encoders.

Does anyone have any opinions about whether I should, or should not, push it?

Naturally it would need docs, but you basically just need to connect
joint-pos-fb to the resolver module so that it can see the value read
in from the position.txt file and set a bit parameter to say "wait for
that value"

https://github.com/LinuxCNC/linuxcnc/commit/0ece124eb52ad6b723db326543714af66ed1930a



This should also work for any 1 turn absolute encoder (like the common Hall 
effect encoders from AMS etc)



--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
?? George Fitch, Atlanta Constitution Newspaper, 1916

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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

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

[Peter C. Wallace]

On Tue, 26 Jun 2018, Curtis Dutton wrote:


Date: Tue, 26 Jun 2018 14:16:16 -0400
From: Curtis Dutton 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver
support + new HAL pin type "PORT"

Ok makes sense. I found the datapainter.vhd in the hostmot2 source code

downloaded from mesanet. Doesn't look like it is in the linuxcnc git yet.

The regmap file in the hostmot2 source shows the DataPainter register map (a 
little easier than trying to decipher the VHDL)




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


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

I think this is unrelated to the smart-serial stream datatype. (So
your smart-serial board is not relevant)

The files that would need to be altered would be the same ones as were
altered to add led support (I choose that one as being a very simple
patch for a very simple feature).

https://github.com/LinuxCNC/linuxcnc/commit/920b18a1e3c278c30ab5b99ad0e441
fbbc2010b9

Basically a new driver file, adding that to the makefile and a few
changes in hostmot2.c / .h  to recognise the tags and to know what to
do with them.

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
?? George Fitch, Atlanta Constitution Newspaper, 1916


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


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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

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

[Peter C. Wallace]

On Mon, 25 Jun 2018, Curtis Dutton wrote:


Date: Mon, 25 Jun 2018 10:24:26 -0400
From: Curtis Dutton 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver
support + new HAL pin type "PORT"

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

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



I do have firmware for this now = DataPainter module

This is a device similar to our stepgen hardware but instead of outputing 
steps, it outputs bits or 8 bit PWM at the requested rate. The data comes from 
a small FIFO (32 deep by 32 wide) so can contain 1024 bits or 128 PWM bytes. 
If the host keeps the FIFO full and you allow 1/2 depletion, this gives you a 
512 KHz maximum bit data rate at 1 KHz servo thread or a 64 Khz analog data 
rate using PWM. The stepgen arrangement allows "position locking" the data 
stream to an axis, encoder, clock, calculated length, etc via PID to a small 
fraction of a bit time. A larger FIFO could be added if higher data rates were 
required (up to 10 MHz or so)


There are start and stop compare registers for start of line and line end 
raster data gating (so no fill data is needed)


The bad news is that it is untested other tha basic data tests and that there 
is no hm2 driver for it yet (but there is a register map on the latest hm2 
source)



Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] RtNet rt-preempt

[Peter C. Wallace]

On Wed, 4 Apr 2018, mark.vandoesb...@hetnet.nl wrote:


Date: Wed, 04 Apr 2018 22:27:06 +0200
From: mark.vandoesb...@hetnet.nl
Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
To: neotheu...@ymail.com, emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] RtNet rt-preempt

I am currently using a modified version of EMC with RTnet on Xenomai-3
and it works just fine. The latest patch to rtnet was on 2018-02-28, this
was about hardware timestamping in the ethernet mac for IEEE-1588 support.

regards,

Mark.



Interesting, does RT-Net now support more Ethernet MACs?

That was one of the reasons we dropped RT-Net/RTAI and moved to Preempt-RT






"Peter C. Wallace" <p...@mesanet.com> wrote:

On Wed, 4 Apr 2018, Alec Ari via Emc-developers wrote:

> Date: Wed, 4 Apr 2018 19:11:29 + (UTC)
> From: Alec Ari via Emc-developers 
<emc-developers@lists.sourceforge.net>
> Reply-To: Alec Ari <neotheu...@ymail.com>,
> EMC developers <emc-developers@lists.sourceforge.net>
> To: EMC developers <emc-developers@lists.sourceforge.net>
> Cc: Alec Ari <neotheu...@ymail.com>
> Subject: Re: [Emc-developers] RtNet rt-preempt
>
> RTnet only really works on 2.6 kernels. There was some work done for 
kernel 3.2 support but it wasn't usable. It's all EOL at this point and completely 
useless, don't even think about RTnet anymore. Just use preempt-rt with POSIX 
threads over the network. You will have the low-latency ethernet by using the 
hm2_eth driver:

There was work being done on RT-Net for Xenomai, but unfortunately one 
of the
main  developers Gilles Chanteperdrix died in 2016 and I think it is 
abandoned
at this point.

>
>
> 
https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/drivers/mesa-hostmot2/hm2_eth.c
>
> For info on how to configure and use hm2_eth please use:
>
>
> $ man 9 hm2_eth
>
> Alec
>
> 
--
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.



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

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


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

Re: [Emc-developers] writing new firmware to read yaskawa absolute encoder

[Peter C. Wallace]

On Fri, 23 Mar 2018, Peter C. Wallace wrote:


Date: Fri, 23 Mar 2018 07:14:38 -0700 (PDT)
From: Peter C. Wallace <p...@mesanet.com>
Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder

On Fri, 23 Mar 2018, Th?ng L? wrote:


Date: Fri, 23 Mar 2018 16:04:47 +0700
From: "[UTF-8] Th?ng L?" <lethang12...@gmail.com>
Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder

i guess i cant contact UART on mesa 5i25 by linuxcnc, just only can get
data from FIFO. I found a way to solve this problem without touchich uart.c
source but it's not complete.

in 8 bytes serial, the first data is "P" (80 in hexa) and last bytes is
"CR" (13 in hexa).

if i read FIFO data every 1 ms ( speed to read 1 bytes at 9600 baudrate and
10 bit frames), function will stop reading when it sees 80 ( or 13) but i
get only 1 byte that is 80 (or 13). I guess RX FIFO is cleared everytime i
read but i didnt find where that function is in:



When you start looking for the serial data do you clear the FIFO first?
(writing to the FIFO count register clears the FIFO)

Does the low level read function wait for data? (FIFO count not 0)

If you dont do these things its not likely you will get usable data



Also you should read _all_ characters in the FIFO every ms
(meaning you must read the FIFO count first to determine how many to read)

Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] writing new firmware to read yaskawa absolute encoder

[Peter C. Wallace]

On Wed, 21 Mar 2018, Th?ng L? wrote:


Date: Wed, 21 Mar 2018 15:20:12 +0700
From: "[UTF-8] Th?ng L?" <lethang12...@gmail.com>
Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder

i'm using mesa_uart to read serial data but i have a issue. Sometimes,

after sending 8 bytes, the  phase A isnt come back idle state-5V state (it
keeps 0V state).  This mean uart is still getting data after first 8 bytes,then
the UART data shows me rx-bytes = 16, all  rx-data = 0.





Is mesa_uart posible to limit the number bytes UART read?


No, but this is expected if the input is driven low after the data
you must only clear the UART/FIFO when the data line is idle

You can disable RX if you know when the input data will become invalid

(you would also expect to see the framing error bit set in this circumstance)



2018-03-16 23:52 GMT+07:00 Peter C. Wallace <p...@mesanet.com>:


On Fri, 16 Mar 2018, Th?ng L? wrote:

Date: Fri, 16 Mar 2018 23:43:49 +0700

From: "[UTF-8] Th?ng L?" <lethang12...@gmail.com>
Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] writing new firmware to read yaskawa
absolute
encoder

ah, i understood what you mean. thank you very much



2018-03-16 23:30 GMT+07:00 andy pugh <bodge...@gmail.com>:

On 16 March 2018 at 16:27, Thng L <lethang12...@gmail.com> wrote:

> this is a great idea but how can i right-shift the data? Both your way
and
> Peter's way seem have to touch UART  source

No, you can shift the raw data in the HAL component that interprets the
data.

--
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



Actually theres no shifting involved, only manipulating bit 7 of the
8 bit data

Peter Wallace
Mesa Electronics


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





--
L?? Thng
Phone: (+84) 1222443855
Email: lethang12...@gmail.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] writing new firmware to read yaskawa absolute encoder

[Peter C. Wallace]

On Fri, 16 Mar 2018, Th?ng L? wrote:


Date: Fri, 16 Mar 2018 23:43:49 +0700
From: "[UTF-8] Th?ng L?" 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder

ah, i understood what you mean. thank you very much


2018-03-16 23:30 GMT+07:00 andy pugh :


On 16 March 2018 at 16:27, Th??ng L??  wrote:
> this is a great idea but how can i right-shift the data? Both your way
and
> Peter's way seem have to touch UART  source

No, you can shift the raw data in the HAL component that interprets the
data.

--
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


Actually theres no shifting involved, only manipulating bit 7 of the
8 bit data

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

Re: [Emc-developers] writing new firmware to read yaskawa absolute encoder

[Peter C. Wallace]

On Fri, 16 Mar 2018, Th?ng L? wrote:


Date: Fri, 16 Mar 2018 23:27:57 +0700
From: "[UTF-8] Th?ng L?" 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder

this is a great idea but how can i right-shift the data? Both your way and
Peter's way seem have to touch UART source. I dont mind to modify it but if 
need to change firmware is a bit problem with me



No need to change firmware or PktUART driver as long as the PktUART driver is 
"8 bit clean" and Im pretty sure it is


The only thing that changes is that on TX data you must generate the parity
bit before you transfer the data to the driver and on RX , you need to mask 
out bit 7 (or do a parity check in software then mask out bit 7)


These could be handled by a very simple component


2018-03-16 17:53 GMT+07:00 andy pugh :


On 16 March 2018 at 08:52, Th??ng L??  wrote:
> The data frame is: 1 bit start + character 7 bits + 1 bit even parity +
 1
> bit stop. I dont need creat this Frame for TX, if there is anyway that i
> can configure this Frame for RX without touching uart firmware and
> component source?

It sounds like you should be able to configure the UART for 1 start, 1
stop and no-parity and then right-shift the data to lose the parity
bit
(Possibly after checking parity manually)

--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
?? George Fitch, Atlanta Constitution Newspaper, 1916


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





--
L?? Thng
Phone: (+84) 1222443855
Email: lethang12...@gmail.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] writing new firmware to read yaskawa absolute encoder

[Peter C. Wallace]

On Wed, 14 Mar 2018, Rene Hopf wrote:


Date: Wed, 14 Mar 2018 22:53:59 +0100
From: Rene Hopf <reneh...@mac.com>
Reply-To: EMC developers <emc-developers@lists.sourceforge.net>
To: EMC developers <emc-developers@lists.sourceforge.net>
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder



On 14. Mar 2018, at 17:54, Peter C. Wallace <p...@mesanet.com> wrote:

Typically there would be no issue sending and receiving 7 bit characters 
with the PacketUART (just mask bit 7 on RX and set it to the line idle 
(high) state on TX )


thats not how uart works, if there is a stop bit, and usually there is.


Umm, works for me...

That is for TX you can add the stop bit in the data (extra stop bits on 
TX only slow the data rate slightly) Note that stop bits are in the idle line 
state.


for RX 7 bit data in a 8 bit UART will work fine as long as data has 2 stop 
bits or a parity bit (or is not sent with end-end characters)




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


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

Re: [Emc-developers] writing new firmware to read yaskawa absolute encoder

[Peter C. Wallace]

On Wed, 14 Mar 2018, andy pugh wrote:


Date: Wed, 14 Mar 2018 16:43:39 +
From: andy pugh 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] writing new firmware to read yaskawa absolute
encoder

On 14 March 2018 at 04:38, Th??ng L??  wrote:
unfortunately, channel A use serial interface with ASCII 7bits, i guess i
cant use mesa_uart without modify uart.c. Does pktuart allow me to change
frames? I was looking at hm2_pktuart_setup function, there is  an option
"Bit 20..16 Frames received", is this what i need?



As far as I can tell from the regmap file the Mesa UART is fixed at 8 bits.
I can't even find pktUART in the regmap to find out if that is different.

Looking at the VHDL files both UART and pktUART have a 4-bit field for
bit-count, so that rather suggests that there should be a way to set
the number of bits to a value other than 7.


--
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


Typically there would be no issue sending and receiving 7 bit characters with 
the PacketUART (just mask bit 7 on RX and set it to the line idle (high) state 
on TX )



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] FlipFlop

[Peter C. Wallace]

On Thu, 16 Nov 2017, Jon Elson wrote:


Date: Thu, 16 Nov 2017 10:50:58 -0600
From: Jon Elson 
Reply-To: EMC developers 
To: EMC developers 
Subject: Re: [Emc-developers] FlipFlop

On 11/16/2017 09:08 AM, andy pugh wrote:

Someone on the forum has noticed that the output pin of the Flipflop
component is of IO type

This seems slightly odd. (It is a compnent that has had very little 
attention)

https://github.com/LinuxCNC/linuxcnc/commits/master/src/hal/components/flipflop.comp


It looks like (I'm no expert on the code behind comp) that it might actually 
be functional to set or clear the FF by writing a value to out.  So, almost 
no way to tell if anyone is actually USING it that way!


Jon


Yes, I tried it and it works as expected (setp-ing the output true or false 
sticks )


Whether is was intended to work this way, perhaps only the author knows.

At the risk of showing my age, I think you could do this on some early (RTL) 
hardware flip flops...




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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


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

Re: [Emc-developers] Mesa 7i90 and 7i43 EPP mode

[Peter C. Wallace]

On Tue, 13 Jun 2017, Bertho Stultiens wrote:


Date: Tue, 13 Jun 2017 15:57:30 +0200
From: Bertho Stultiens 
Reply-To: EMC developers 
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] Mesa 7i90 and 7i43 EPP mode

Hi,

Is there a way to detect the difference between the 7i90 and 7i43 boards
over EPP communication? I was looking into these drivers and they are
essentially the same (very small difference if you take the variable
naming out of the picture).


Yes, and I think there could be a unified driver for both

The reason the 7I43 driver doen't work with the 7I90 is that it assumes that 
it needs to download firmware into the card at startup (So also fails with 
7I43s that are set to load firmware from their local EEPROM)


Probably the best thing for the driver to do is assume that if the driver 
command line has a firmware token, that it should download that firmware and 
if not, assume the FPGA is loaded and probe for a valid HostMot2 cookie and 
card name (firmware downloading direct to an unprogrammed FPGA is only 
possible with the 7I43, not a 7I90)




I have been pondering to add yet another RPI driver doing EPP emulation
on the GPIO pins. It would at least as fast as SPI communication and has
the potential to be faster (especially if the EPP slave relaxes the
timing a bit).

The advantage of EPP emulation is in the reduced frequency on the
pysical communication lines and would be at least four times lower. The
physical bottleneck would be on strobe-timing. That may be an advantage
in noisy environments and the overhead on the RPI is not any greater
than using SPI (which is also polled in a busy-loop).

If both 7i90 and 7i43 can be differentiated over EPP at runtime, then a
unified EPP driver is more easily created. Otherwise you need a module
parameter to distinguish or duplicate most of the code.

Any comments, thoughts or suggestions?

--
Greetings Bertho

(disclaimers are disclaimed)

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



Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


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

Re: [Emc-developers] [Emc-users] Spindle speed signal

[Peter C. Wallace]

On Thu, 8 Dec 2016, andy pugh wrote:


Date: Thu, 8 Dec 2016 18:19:53 +
From: andy pugh 
Reply-To: "Enhanced Machine Controller (EMC)"

To: EMC developers 
Cc: "Enhanced Machine Controller (EMC)" 
Subject: Re: [Emc-users] [Emc-developers] Spindle speed signal

On 8 December 2016 at 18:10, Robert Ellenberg  wrote:
Does anyone use a spindle encoder with only position output? In other
words, encoder position linked to  motion.spindle-revs, but no input to
motion.spindle-speed-in?

I would imagine that it might be uncommon, but not unknown. For
example a serial encoder might not have velocity data.


I think thats true with the HM2 SSI BISS and FANUC encoders

Not sure if its possible but you might consider doing something
like the PID component which detects if pid.N.feedback-deriv
is connected and calculates  a local  d/dt velocity if not



--
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

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Emc-users mailing list
emc-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] serious PCIe parallel port problem

[Peter C. Wallace]

On Sat, 9 Apr 2016, Jon Elson wrote:

> Date: Sat, 09 Apr 2016 14:27:24 -0500
> From: Jon Elson 
> Reply-To: EMC developers 
> To: EMC developers 
> Subject: [Emc-developers] serious PCIe parallel port problem
> 
> Well, I'm in BIG trouble.
>
> I have 3 PCIe parallel port cards here that are all doing
> the same thing.  They are, however, all the exact SAME PC
> board with the Oxford OXPCIe952 chip.  They are branded
> SIIG, Startech and Rosewill.  I cannot get them to work with
> my PPMC-family boards.  I hooked up the logic analyzer, and
> my diagnostic program does a series of writes to the board
> that all look OK.  Then, it tries to enumerate the board,
> and this involves an address write and then a data read, and
> the read is not performed at ALL.  (The data writes
> performed previously all look fine, WRITE/ is asserted with
> the data lines, then DATASTB/ is pulsed and WAIT/
> acknowledges the cycle.) For the reads, WRITE/ goes low with
> the address to be read on the data lines, ADDRSTB/ is
> pulsed, WAIT/ acknowledges it.  THEN, WRITE/ is supposed to
> stay high, and DATASTB/ SHOULD be pulsed, but NOTHING happens!
>
> The only thing I can figure is that the reconfiguration I've
> been using for well over a DECADE to turn the bus from write
> mode to read mode has somehow disabled the EPP data cycle.
>
> As far as I know, the way I'm doing this is approved and
> recommended by all the experts who have written how to do
> EPP transfers at the PC register level.
>
> Setting the port to write mode :  write 0x04 to controlport
>
> Setting the port to read  mode :  OR 0x20 to controlport
>
> Anybody ever done EPP programming that might have some ideas?
>
> Jon
>
>

You might see if the data sheet is available from
Avago

(Oxsemi was bought out by PLXTech which was subsequently bought out by 
Avago)


Peter Wallace
Mesa Electronics

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] tandem PID steppers - 1 or 2 PIDs

[Peter C. Wallace]

On Sun, 13 Mar 2016, Chris Morley wrote:

> Date: Sun, 13 Mar 2016 20:30:17 +
> From: Chris Morley 
> Reply-To: EMC developers 
> To: EMC DEV 
> Subject: [Emc-developers] tandem PID steppers - 1 or 2 PIDs
> 
> Looking to fix up tandem steppers in pncconf.
> This is using Mesa stepgens.
>
> Would it work fine to use one PID loop to control
> the two stepgens?
>
> basically ignore the second stepgens fb.
>
> Thanks
> Chris M


I dont think so, there is nothing to keep one stepgens position from slowly 
drifting away from the others during acceleration due to slight differences in 
position read and in velocity write times. These offsets would be small and 
should cancel out but I dont get the warm fuzzys that long term position drift 
is impossible with this approach.

Also this would prevent the (useful) addition of position offsets between
stepgens (like the Gantry comp does)



>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] About the header file "ioctl.h" in HAL?

[Peter C. Wallace]

On Sun, 28 Feb 2016, Jeff Epler wrote:

> Date: Sun, 28 Feb 2016 09:37:07 -0600
> From: Jeff Epler 
> Reply-To: EMC developers 
> To: EMC developers 
> Subject: Re: [Emc-developers] About the header file "ioctl.h" in HAL?
> 
> It sounds like you are using RTAI realtime, which builds all realtime
> components as kernel modules.
>
> The header  is not suitable for use when building a kernel
> module.
>
> Since no drivers in linuxcnc use rtnet, I do not have any examples to
> point you towards.  I suggest you read rtnet documentation, it should
> clarify what headers you can use for networking features.
>
> The existing ethernet driver in linuxcnc 2.7, hm2_eth, only works with
> "uspace" realtime where realtime runs as a standard linux process but
> real-time scheduling priority.  Components are just shared libraries,
> and hm2_eth makes regular userspace socket calls.
>
> Jeff


The original hm2-eth driver used RT-Net and RTAI, the origin/ubc3-7i80
branch.

We temporarily gave up on RT-Net since it seemed to be abandoned and MAC 
drivers for current hardware were unavailable. We changed to Preempt-RT
and using the stock network stack as a stop-gap until RT-Net 
caught up, but it turned out that real time network performance with 
Preempt-RT and the stock linux stack was perfectly adequate for servo thread 
update rates and had the advantage of supporting a wider range of 
hardware so at least for our purposes RT-Net doesn't really have any 
advantages.

Now that RT-Net been adopted by the Xenomai project, it may become better 
supported.


Peter Wallace
Mesa Electronics


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RTAI ethernet

[Peter C. Wallace]

On Sun, 17 Jan 2016, Karlsson & Wang wrote:

> Date: Sun, 17 Jan 2016 16:37:21 +0100
> From: Karlsson & Wang 
> Reply-To: EMC developers 
> To: Alec Ari 
> Cc: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] RTAI ethernet
> 
>> I believe the hostmot2 ethernet drivers only work (or at least have only 
>> been tested) with PREEMPT_RT.
>>
>> Alec Ari
>
> PREEMPT_RT work but it is not possible to put the limit then it come to 
> period of how often real time tasks could be executed. Without proper 
> handling of interrupt every now and then there will be a delay by the time 
> it take to execute the interrupt. I also expect sometimes several will 
> happen at once and even though it is rare with a machine running several 
> hours a day it happens sometimes.

Not true at all

On Preempt-RT, most hard interrupts are converted to preemptable kernel 
threads with assignable priorities. On the average, Preempt-RT latency is not 
quite as good as RTAI but specific versions of Preempt-RT are better than RTAI 
and Preempt-RT is getting better all the time.

I have more than 2 machine years of hm2_eth uptime running under 
Preempt-RT (with > 1 machine year running at 4 KHz) and have not had 
any latency issues ( Peak round trip network jitter on the 4 KHz machine
is in the 30 usec region over a year of operation and running compiles, 
youtube videos etc )



>
> I run software on microcontrollers with the Cortex-* CPU and sometimes use 
> the nested interrupt controller as hardware scheduler and get in all essense 
> perfect real time scheduling.
>
> Without proper handling of priorities for interrupts it is only possible to 
> use a rather small percentage of available clock cycles for real time tasks 
> since delay caused by interrupts must be added to real time tasks execution 
> time.
>
>
> Nicklas Karlsson
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Difference RTAI 5.0 <--> PREEMPT-rt ?

[Peter C. Wallace]

On Sun, 3 Jan 2016, Niemand Sonst wrote:

> Date: Sun, 3 Jan 2016 19:59:41 +0100
> From: Niemand Sonst 
> Reply-To: EMC developers 
> To: EMC developers 
> Subject: Re: [Emc-developers] Difference RTAI 5.0 <--> PREEMPT-rt ?
> 
> Yes,
>
> in some words:
>
> RTAI is much faster, but relies on the kernel you have, so it is much
> more complicated to be included in software parts.
> It is mostly needed only for very high speed applications
>
> PREEMPT-RT is a a little bit slower than RTAI, but can be implemented in
> software much easier, just imagine it is a modul.
>
> That is very simple explained, there are more differences. For a normal
> CNC opperation both should work fine. But if you use i.e. software
> stepgenerator over a LPT, than take the RTAI.
>
> Norbert

Depending on the hardware the differences between RTAI and Preempt-RT may be 
minimal:

http://freeby.mesanet.com/g3258-rtai.png
http://freeby.mesanet.com/h97-g3258-preemt-rt.png

Both about 1/2 a day of YouTube videos (I favor the crackling fireplace ones) 
and 10 glxgears each

I'll try some Skylake hardware when I can figure out how to build the latest 
(4.4-rc6-rt1) Preempt-RT kernel

Note that both the latency test and latency histogram mainly display 
_dispatch_ latency. Actual latency to _do_ anything (allocate memory, do I/O, 
access the PCI bus, etc) will be significantly worse


Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] jerk limited trajectory

[Peter C. Wallace]

On Tue, 22 Dec 2015, Chris Morley wrote:

> Date: Tue, 22 Dec 2015 18:25:10 +
> From: Chris Morley 
> Reply-To: EMC developers 
> To: EMC DEV 
> Subject: Re: [Emc-developers] jerk limited trajectory
> 
>
>
>> Date: Tue, 22 Dec 2015 11:18:20 -0600
>> From: el...@pico-systems.com
>> To: emc-developers@lists.sourceforge.net
>> Subject: Re: [Emc-developers] jerk limited trajectory
>>
>> On 12/21/2015 11:59 PM, Chris Morley wrote:
>>>
>>> That version of jerk-limited just didn't quite work right
>>> with spindle-synch. IIRC the person doing it didn't need
>>> spindle-synch and got little help - lost interest. Not
>>> that i blame him - it looks very difficult!
>> Yes, I think combining jerk limiting with spindle synch
>> REQUIRES a compromise.  There are probably a couple ways to
>> do it.  One is to just turn off jerk limiting when in
>> spindle synch.  The other is to warn users that there is
>> some initial part of the motion which will not be fully
>> synched to the spindle, until the jerk limit has been
>> integrated out.  This latter scheme will break taps on
>> spindle reversal, so doesn't seem like the right approach.
>> Maybe somebody else knows a better way?
>>
>> Jon
>>
>
> I've heard this argument before and it just doesn't make sense to me.
> I can't figure out why one would not want to have jerk limiting.
> jerk limiting allows one to define a machine command that the machine
> can actually physically perform. In fact it can allow you to raise 
> acceleration
> setting giving you more performance.
> If ignoring jerk allowed better performance then ignoring acceleration should 
> be
> even better? I don't think that would be very successful.
> I mean obviously if your jerk setting is out to lunch that could be just as 
> bad.
> but I bet jerk is such a small part of machine movement that it wouldn't 
> break the tap.
> I say this because all linuxcnc machines out there ignore jerk and they don't 
> break taps
> all the time. Though i guess one could argue that the axis has jerk anyways 
> so it matches
> the spindle close enough.
>
> I am not an expert or have done the math on this - it just doesn't make sense 
> to me.
> I'd love to know the answer definitively!
> It would be interesting to see the actual motion profile of a spindle tapping 
> vrs
> the actual motion profile of an axis following it vrs the commanded motion 
> profile.
>
> Interesting !
>
> Chris M

I suspect (but do not know for sure) that VFDs are slow enough at developing 
reverse torque (so are inherently low jerk) that this is not really an issue
as long as the synchronized axis jerk value is high enough to follow without 
bounding acceleration.

Of course, with a fancy spindle control (say closed loop), the spindle jerk 
could be limited.

Peter Wallace
Mesa Electronics


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

Re: [Emc-developers] Emc-developers Digest, Vol 114, Issue 13 (Ethernet, STM32F407)

[Peter C. Wallace]

On Tue, 13 Oct 2015, Rene Hopf wrote:

> Date: Tue, 13 Oct 2015 15:49:59 +0200
> From: Rene Hopf 
> Reply-To: EMC developers 
> To: EMC developers ,
> Karlsson & Wang 
> Subject: Re: [Emc-developers] Emc-developers Digest, Vol 114,
> Issue 13 (Ethernet, STM32F407)
> 
>
>>
>> I use the STM32F407 with the hostmot2 driver. I had some glitches at startup 
>> but today I added a small delay someone here suggested end then startup 
>> works perfect every time with two cards connected.
>>
>> I have been running two axes with DC servo motors and ordinary encoders on 
>> one of the cards although both cards should be used to get 4 axis. I ran 
>> servo loop at 1kHz but expect somewhat faster will also work.
>
> Hi, currently I am working on a similar project involving a ethernet based 
> board to control my own servo drives: https://github.com/rene-dev/stmbl
> Is anyone of you willing to share some code? I already started implementing a 
> server for the hm2_eth protocol, but maybe we can work together?
> my idea is to use rs485 to control the drives, as it is much better than 
> step/direction.
> the stmbl hardware also supports smart serial, but there is a lot of software 
> to do.
> is there any smartserial client code available?
>
> Rene
> --


Well... sort of

One of the 7I90 firmware options is to run as a simple (72 DIO) sserial remote

The processor code for the remote is part of the hostmot2 firmware source
(in ssremote.zip)

Its written in a quite obscure assy language. but _might_ be somewhat 
comprehensible if combined with the sserial protocol description thats in the 
back of all sserial remote manuals




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

Peter Wallace
Mesa Electronics

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

Re: [Emc-developers] Weirdest lcnc problem yet

[Peter C. Wallace]

On Wed, 7 Oct 2015, Gene Heskett wrote:

> Date: Wed, 7 Oct 2015 19:31:06 -0400
> From: Gene Heskett 
> Reply-To: EMC developers 
> To: EMC developers 
> Subject: [Emc-developers] Weirdest lcnc problem yet
> 
> Greetings all;
>
> My GO704 box has decided it cannot find the RTLIB modules.
>
> I have tried to export the path in both my own .basrc, and in
> /etc/profile, but the only way to make it show up in an "env"
> output is to export it from the command line of every terminal,
> AND terminal window tab that I open.  And even that does not help.
>
> It simply cannot find hm2_pci.ko according to the messages it emits as
> its cleaning up.  It leaves this in the window that tries to run it:
> =
> gene@GO704:~$ linuxcnc -l
> LINUXCNC - 2.8.0-pre1-1138-gd40e5d4
> Machine configuration directory is '/home/gene/linuxcnc/configs/GO704fast'
> Machine configuration file is 'GO704fast.ini'
> Starting LinuxCNC...
> .
> Found file(REL): ./GO704fast.hal
> Error: could not insert module 
> /usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc/hm2_pci.ko: No such device
> ./GO704fast.hal:8: exit value: 1
> ./GO704fast.hal:8: insmod for hm2_pci failed, returned -1

That normally means it cannot find the FPGA card
most often this is a PCI contact issue

Check with lspci -vn | grep 5125

( should print something with 2718:5125 )

occasionally its because of a marginal 3.3V ATX PS
( symptoms of this are the red lights on 5I25 staying on or blinking any time 
other than power up)



Peter Wallace
Mesa Electronics



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

Re: [Emc-developers] "LinuxCNC Features"

[Peter C. Wallace]

On Mon, 14 Sep 2015, Sebastian Kuzminsky wrote:

> However, I don't like the name "LinuxCNC Features" for the name of a
> conversational front-end.  To me that sounds like an enumeration of the
> things LinuxCNC can do.
>


LiveCAM?


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

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


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

Re: [Emc-developers] LinuxCNC on ARM + Mesa

[Peter C. Wallace]

On Fri, 14 Aug 2015, Thomas Gambone II wrote:

 Date: Fri, 14 Aug 2015 13:22:07 -0400
 From: Thomas Gambone II tgamb...@comtime.com
 To: EMC developers emc-developers@lists.sourceforge.net
 Cc: Jeff Epler jep...@unpythonic.net
 Subject: [Emc-developers] LinuxCNC on ARM + Mesa
 
 Hello all!

 First time mailing back to the list.

 Wanted to ask the list / Jeff Epler a couple specific questions related to
 his work on the ARM platform (Odroid U3) + Mesa 7i90 (SPI).

 In looking through the available daughter cards from Mesa, there's nothing
 quite as nice as the 7i76, 7i77, or 7i78 (DB25) boards available with the
 HD50 interface (kind used by 7i90).

 Notably, I don't see any card in the HD50 family that has built in stepgen.

You can use a 7I52S or 7I47

You can also use any of the DB25 daughtercards with a proper (hand made) cable

I  intend to make a 4x 26 pin header version of the 7I90 when I get a 
chance to make using DB25 daughtercards easier


 What card(s) can you recommend to use with the 7i90 for general 3-axis+ CNC
 control.

 As well, in reading the detailed version of Jeff's blog post regarding the
 Odroid U3 (http://emergent.unpythonic.net/odroid-u3), he mentions that
 because the ethernet connection on the board is connected via USB[2.0] it
 is no good for use with hostmot2_eth.

 I've got a new XU4, which is basically the U3, with a beefier octa-core
 processor (still Samsung Exynos) and USB3.0 ports. The ethernet is hooked
 in via USB3.0 and is gigabit on this board.

 Would it be possible to use a hostmot2_eth board (like the 7i76E) with a
 USB3.0 to gigabit ethernet connection?

 Thank you,
 -Tom

Maybe, but USB Ethernet interfaces seem to have occasional long latencies

I can run hm2_eth cards on my USB-1GE dongle for maybe an hour or so before I 
get a 8 ms latency.

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


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.


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

Re: [Emc-developers] research on optical encoders

[Peter C. Wallace]

On Mon, 10 Aug 2015, Nicholas Mc Guire wrote:

 Date: Mon, 10 Aug 2015 08:40:02 +0200
 From: Nicholas Mc Guire der.h...@hofr.at
 Reply-To: EMC developers emc-developers@lists.sourceforge.net
 To: EMC developers emc-developers@lists.sourceforge.net
 Subject: Re: [Emc-developers] research on optical encoders
 
 On Sat, 08 Aug 2015, Peter C. Wallace wrote:


 I think the trick the Resolute encoder uses is this: the image is captured 
 in
 a perhaps sub microsecond flash of the LED, and then the image can be
 shifted out of the sensor at a leisurely rate. The specifications sort of
 suggests this (very fast capture (ns) time, but only multi KHz maximum 
 update
 rate)

 Peter Wallace
 Mesa Electronics


 They may in fact use a laser for illumination as AFAIK you can get higher 
 peak
 power with a pulsed laser than a LED. These are in the $30 region for 75W 
 peak
 40 ns pulse width, not much vibration or motion blur in 40 ns :-)


 the problem is not the vibration in the 40ns
 but that the recorded encoder image is more or less
 a random position within the vibration range of
 the device + vibration of the laser - I was thinking
 about compensations like done with satelite images
 where multiple pictures are taken and then the signals
 are compensated by filtering out szintilation effects

 If the actual sampling is in the multi kHz range only then
 that would be well in the modes that such systems can have
 and one - worst case - would have the full vibration in
 the positional information. Just wonder if there are any
 detection algorithms that look into such issues. Naively
 one could do a fft on the position data under the assumption
 that motion should be constant/known-trajectory and that
 could reveale such vibration/aliasing induced errors.

 http://www.osram-os.com/osram_os/en/products/product-catalog/laser-diodes/high-power-laser-diodes/pulsed-laser-diodes/hybrid-pulsed-laser-diodes/index.jsp

 ( thank you Harold Edgerton )

 thx!
 hofrat


Not sure vibration in the 10 KHz and up range is a serious problem here as it 
takes significant energy to get even tiny displacements at 10 KHz or so in the 
heavy mechanics used with precision encoders. Motion blur _is_ an issue but 
this is solved by the strobed lighting.




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


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.


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