Re: [Emc-users] Rpi Pico

[Dave Cole]

I see that Sparkfun now has them on backorder.

Sparkfun shipped my order today.   So that's good.
Ironically Sparkfun had a limit of 100 per customer.
I suspect you might find them being resold on Ebay.

Yep.
https://www.ebay.com/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=raspberry+pi+pico&_sacat=0

Oh well.

Dave


On 1/23/2021 1:49 PM, Chris Albertson wrote:

They seem to have done an excellent job of getting the word out about this
new product.  I think that it will be the "new Arduino" but the current
problem is actually buying them.   I've signed up to be notified when more
are available but you have to be quick and lucky as they sell out in
minutes.

This is not really a bad thing.  It means they have something people want
and at $4 the price is right.  In a month they will be generally available
in quantity with Amazon-prime 2-day shipping.

In the meantime, there is a ton of documentation to download and read.



On Fri, Jan 22, 2021 at 1:28 PM Frank Tkalcevic 
wrote:


I just received an advertising email from SparkFun.  They sell the Pi Pico
as well as 3 of their own variants with the RP2040 chip...


Thing Plus - https://www.sparkfun.com/products/17745
MicroMod - https://www.sparkfun.com/products/17720
Pro Micro - https://www.sparkfun.com/products/17717

I just noticed, they are for pre-order.


-Original Message-
From: Chris Albertson [mailto:albertson.ch...@gmail.com]
Sent: Friday, 22 January 2021 4:05 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Rpi Pico

On Thu, Jan 21, 2021 at 7:56 PM Dave Cole  wrote:


I was thinking multiple RPi Picos to one RPi4, but for just one, that is
probably the way to go.


The Pico is a dual-core M0.   So it is faster than I had originally
thought.   Micro-Python is ported to it so it might be very easy for many
people to program.   I'm got my name in to be notified when they are back
in stock. I still think USB is the simplest way to connect while
experimenting.

One advantage of USB is that you need USB to program the Pico.   You would
run the development system on the Pi4 and change the firmware by copying
files or drag/drop.  If the Pico is SPI connected then you need to hunt
down a USB cable then walk out to the shop to change the firmware.




I'll try that first!

The Pi Hat as the carrier board is also a good idea.

On 1/21/2021 7:46 PM, Chris Albertson wrote:

I'd bet SPI would work well but even easier would be to connect them to

the

Pi4 with USB.  Both sides have software that makes the USB look like a
serial port and the physical connection is done with off the shelf

cable.

I've used M0 boards this way in the past and using USB lets you also

cnet

them to a Linux PC

What I like about the Pico is that it can be SMT hand soldered.  I can

make

a simple passive carrier board that has connectors and it is not hard

to

hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat

On Thu, Jan 21, 2021 at 4:30 PM Dave Cole 

wrote:

I wonder if these could act as SPI slaves to the RPI 4?

I've been trying to buy two from Adafruit and they keep selling out

and

then coming back in stock, and then selling out again!

Dave

On 1/21/2021 6:36 PM, andy pugh wrote:

On Thu, 21 Jan 2021 at 21:52, Chris Albertson <

albertson.ch...@gmail.com>

wrote:

This is an STM32 microcontroller.

Are you sure? It is an ARM Cortex M0, like the STM32, but is it made

by

ST?

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



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



--

Chris Albertson
Redondo Beach, California

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



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






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

[Emc-users] camview or emccam or emc_cam

[Gene Heskett]

Greetings all;

My new camera for the mill arrived today, and looks great pix wise using 
luvcview.  But since its never been installed on the 6040, none of any 
of those camview utility's can be found on the machine, and my goggle-fu 
is on strike, all it can find for a emc_cam search is an exersize gym in 
Pheonix AZ. Which obviously is not what I have in mind.

So, where do I get the latest, hopefully all bug fixed version of that 
camera/edgefinder utility?

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

Re: [Emc-users] Carousel component indexing/trigger problem

[Andreas Linnarsson]

Hi,

The project has been on hold for slightly more than a week but I managed to
get it work, with one exception. Homing, forward jog and pre-homed Tn M6
works great. The only problem is that the combined homing and Tn M6
procedure makes it go one step too far now since it goes directly from
homing to tool change without reversing in between. This is of course
logical but it breaks the program logic that I added that makes the
carousel go one step further during every tool change. So I have to add
some functionality that will deduct that extra step if a Tn M6 command is
issued and the turret isn't homed.

The solution isn't glodal yet, the code I've added will break the
functionality for tool changers that doesn't require the extra step but my
plan is to add the proper evaluations to fix this. There might also be a
need to add an extra argument to the carousel in order to make it
distinguish between one-way tool changers that locks in place without
backing off the encoder (if that type exist), and this Emco-style my lathe
is equipped with, that does back off the encoder during locking.

Den lör 23 jan. 2021 kl 01:34 skrev andy pugh :

> On Thu, 14 Jan 2021 at 10:35, andy pugh  wrote:
>
> > Note: As it stands jogging won't work as current_position is one less
> > than the actual position.
> > Did you check M6 Tnn commands, or only jogging?
>
> Where are we with this?
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

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

Re: [Emc-users] CANopen on LinuxCNC

[John Dammeyer]

> From: Nicklas SB Karlsson [mailto:nk@nksb.online]
> 
> Den 2021-01-23 kl. 01:31, skrev John Dammeyer:
> >> From: andy pugh [mailto:bodge...@gmail.com]
> >> On Fri, 22 Jan 2021 at 23:16, John Dammeyer  wrote:
> >>
> >>> And I take it from your answer that this sort of driver at this point in 
> >>> time does not exist.
> >> Not as far as I know, but it might be a fairly simple thing to create.
> >> It need to create HAL pins then gather the data from wherever, and put
> >> it on the HAL pins.
> >>
> >> --
> > That's probably more of a patchy method.
> >
> > CANopen has a number of states and needs some sort of master to co-ordinate 
> > the state changes.
> > INIT, PRE-OPERATIONAL and OPERATIONAL are the 3 main ones.  There's also an 
> > ERROR and STOPPING etc.
> 
> If I remember correct CANopen devices start in pre-operational mode, a
> SYNC is usually sent periodically and just because of this.

The start with a RESET status message.  Then PRE-OP.  The SYNC is not needed or 
required.  The transition to OPERATIONAL happens when the NMT master decides 
it's ready for that.

> 
> 
> Once devices are configured data in the PDOs need to be mapped in hal
> and this require some more driver support.
> 
> 
> It is probably also useful with SDO communication which is usually used
> to configure devices. Configuration may equally well may be done by
> external tool if CiA309-3 gateway is implemented, protocol is text but
> graphical user interface may communicate using it have, have a simple
> one currently hardcoded entries.

I disagree.

The full CANopen spec is designed to be infinitely configurable making much of 
it very complicated.  Dynamic configuration of devices on power up, although 
possible isn't required for a fixed hardware product that doesn't change.  This 
adds complexity.

Once I finish my mill cabinet upgrade and a few other projects I do intend on 
getting back to my CANopen Lite project which includes an application for 
working with CANopen messages.

Things were going really well until I ran into the issue that the Lazarus 
sockets library did not support SocketCAN the way that the C and Python 
libraries do.  Which means I have to upgrade sockets.pp first.  And that's 
where I stopped and restarted other unfinished projects.

The attached screen shots show however that it did work with the Lawicel 
CANUSB.  This software is written with the "Write Once" "Compile anywhere" 
model and therefore has been tested and runs on WIN-7, WIN-10, Raspberry Pi3B, 
BeagleBone Black and LinuxCNC.  

CANopen Lite is designed to work as a simpler version of CANopen that doesn't 
have all the bells and whistles that a full CANopen implementation might.  
However it has been tested with COTS CANopen devices like displays, battery 
chargers, and CANopen based servo motors.  

In addition to the desktop application there will be a number of different 
CANopen device samples that demonstrate how to create say a display module, 
relay module or I/O module etc.  Maybe even a motor or two.

Mapping HAL PINs into Object Dictionary locations is the easiest way to deal 
LinuxCNC.  A readable configuration file in the same way that the HAL file is 
read on start-up is one way to populate the object dictionary with the HAL PINs 
that someone will want made visible on the CAN bus.  It will all depend on how 
access to the PINs is granted at the core program level.

Anyway, it's a work in progress.  Be a few months before I can get back to it 
and I really want access to Raspberry Pi HAT MCP2515 CAN devices and the 
internal CAN devices in a Beaglebone Black.  And for that, there's some low 
level OS library work required.

John Dammeyer



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

Re: [Emc-users] Rpi Pico

[Chris Albertson]

They seem to have done an excellent job of getting the word out about this
new product.  I think that it will be the "new Arduino" but the current
problem is actually buying them.   I've signed up to be notified when more
are available but you have to be quick and lucky as they sell out in
minutes.

This is not really a bad thing.  It means they have something people want
and at $4 the price is right.  In a month they will be generally available
in quantity with Amazon-prime 2-day shipping.

In the meantime, there is a ton of documentation to download and read.



On Fri, Jan 22, 2021 at 1:28 PM Frank Tkalcevic 
wrote:

> I just received an advertising email from SparkFun.  They sell the Pi Pico
> as well as 3 of their own variants with the RP2040 chip...
>
>
> Thing Plus - https://www.sparkfun.com/products/17745
> MicroMod - https://www.sparkfun.com/products/17720
> Pro Micro - https://www.sparkfun.com/products/17717
>
> I just noticed, they are for pre-order.
>
>
> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: Friday, 22 January 2021 4:05 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Rpi Pico
>
> On Thu, Jan 21, 2021 at 7:56 PM Dave Cole  wrote:
>
> > I was thinking multiple RPi Picos to one RPi4, but for just one, that is
> > probably the way to go.
> >
>
> The Pico is a dual-core M0.   So it is faster than I had originally
> thought.   Micro-Python is ported to it so it might be very easy for many
> people to program.   I'm got my name in to be notified when they are back
> in stock. I still think USB is the simplest way to connect while
> experimenting.
>
> One advantage of USB is that you need USB to program the Pico.   You would
> run the development system on the Pi4 and change the firmware by copying
> files or drag/drop.  If the Pico is SPI connected then you need to hunt
> down a USB cable then walk out to the shop to change the firmware.
>
>
>
> > I'll try that first!
> >
> > The Pi Hat as the carrier board is also a good idea.
> >
> > On 1/21/2021 7:46 PM, Chris Albertson wrote:
> > > I'd bet SPI would work well but even easier would be to connect them to
> > the
> > > Pi4 with USB.  Both sides have software that makes the USB look like a
> > > serial port and the physical connection is done with off the shelf
> cable.
> > >
> > > I've used M0 boards this way in the past and using USB lets you also
> cnet
> > > them to a Linux PC
> > >
> > > What I like about the Pico is that it can be SMT hand soldered.  I can
> > make
> > > a simple passive carrier board that has connectors and it is not hard
> to
> > > hand solder 0.1 inch pitch.  The carrier board could be a Pi-hat
> > >
> > > On Thu, Jan 21, 2021 at 4:30 PM Dave Cole 
> > wrote:
> > >
> > >> I wonder if these could act as SPI slaves to the RPI 4?
> > >>
> > >> I've been trying to buy two from Adafruit and they keep selling out
> and
> > >> then coming back in stock, and then selling out again!
> > >>
> > >> Dave
> > >>
> > >> On 1/21/2021 6:36 PM, andy pugh wrote:
> > >>> On Thu, 21 Jan 2021 at 21:52, Chris Albertson <
> > albertson.ch...@gmail.com>
> > >> wrote:
> >  This is an STM32 microcontroller.
> > >>> Are you sure? It is an ARM Cortex M0, like the STM32, but is it made
> by
> > >> ST?
> > >>
> > >> ___
> > >> Emc-users mailing list
> > >> Emc-users@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/emc-users
> > >>
> > >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
>
>
> --
>
> Chris Albertson
> Redondo Beach, California
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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

Re: [Emc-users] CANopen on LinuxCNC

[Nicklas SB Karlsson]

Den 2021-01-23 kl. 01:31, skrev John Dammeyer:

From: andy pugh [mailto:bodge...@gmail.com]
On Fri, 22 Jan 2021 at 23:16, John Dammeyer  wrote:


And I take it from your answer that this sort of driver at this point in time 
does not exist.

Not as far as I know, but it might be a fairly simple thing to create.
It need to create HAL pins then gather the data from wherever, and put
it on the HAL pins.

--

That's probably more of a patchy method.

CANopen has a number of states and needs some sort of master to co-ordinate the 
state changes.
INIT, PRE-OPERATIONAL and OPERATIONAL are the 3 main ones.  There's also an 
ERROR and STOPPING etc.


If I remember correct CANopen devices start in pre-operational mode, a 
SYNC is usually sent periodically and just because of this.



Once devices are configured data in the PDOs need to be mapped in hal 
and this require some more driver support.



It is probably also useful with SDO communication which is usually used 
to configure devices. Configuration may equally well may be done by 
external tool if CiA309-3 gateway is implemented, protocol is text but 
graphical user interface may communicate using it have, have a simple 
one currently hardcoded entries.



Nicklas Karlsson


During the PRE-OP state the master can send Service Data Object messages (SDO) 
which are a REQUEST/RESPONSE process.  Once OPERATIONAL all nodes may transmit 
asynchronously Process Data Object messages (PDO).
Devices may send Service Data Objects (SDO) in both pre-operational and 
operational mode, message have priorities so it should even work well if 
there is real time communication going on, there might be a need to do 
configuration via SDO befor device enter operational mode. PDO messages 
may be synchronized by a special SYNC messages but asynchronous is also 
possible, most probably periodically sent SYNC message is the choice 
then using it in Linuxcnc.

CANopen works with an Object Dictionary which theoretically is huge (greater 
than 16MB) and a bit tough on an 8 bit processor with 64k addressability.  So 
the Object Dictionary is broken into a 16 bit index and 8 bit sub index pair 
which points to a data object that could be a bit, nibl, byte, word and even 
string.  You can see how this quickly could become very large.

However internally the Object Dictionaries tend to be lists or groups of tables 
that are accessed via binary searches so it's not as bad as it looks.
Device may follow a standard and best way is to use .dcf or .eds to put 
name on the numbers.

To make LinuxCNC work with CANopen the ideal is to create an Object Dictionary 
that has HAL pins mapped to Object Dictionary entries.  Now the system master 
can send an SDO request for the value of 3001:23 which has a size of 4 bytes.  
The CANopen part of the driver then captures that HAL pin allocated to that 
location and returns it in the Reply Data Object (RDO) message.


Not exactly I would say. Most important is the need to map data in PDO 
messages into hal pins. There is standard entries dictionary possible to 
access using SDO to tell how PDOs are mapped and is usually possible to 
change these mappings if needed. Datatype vary in size and type, usual 
numbers but also the little bit more unusual 24bit real.


Object dictionary devices is available in .dcf or .eds file.


...
The information for what's in a PDO and how often it's sent is also contained 
in pre-defined locations in the Object Dictionary.

Exactly. Think you have to look into .eds or .dcf file to get the datatype.

It's not super complicated.   But it requires something that can run apart 
from, but has access to HAL pins and probably runs at the SERVO_PERIOD rate.  
And obviously a method of updating/reading a 1 to 8 byte value without being 
interrupted by some other task updating it at the same time.


A driver to send at least one message to put devices into operational 
and a periodic SYNC message is needed. There must also be parameters to 
map PDO data into hal pins and create the pins needed.


It is possible to do auto detection of devices by scanning bus but in 
the end signals will be wired up the usual way in hal once figured out 
there way should be connected regardless of how mapping is figured out.



The OD entries connected to HAL pins can be set to be Read Only so it's 
possible to access motion values like position etc. without changing them.  Or 
they can be Read/Write so you can start or stop the spindle with an RPM value.


Yes there is a need for ordinary read/write access on pins as some 
values flow one direction only. There is also a need for datatype size 
and type on pins. And adding the pins needed. Pins not only with 
connected devices but also depending on how they are configured, guess 
explicitly adding these hal pins needed is the method.



Nicklas Karlsson



___
Emc-users mailing list
Emc-users@lists.sourceforge.net

Re: [Emc-users] CANopen on LinuxCNC

[Nicklas SB Karlsson]

Den 2021-01-22 kl. 22:32, skrev John Dammeyer:

Is there an easy way to bring CANopen information into LinuxCNC?


Have done some work on a CiA409-3 gateway including a graphical user 
interface, this is for setting parameters. Will most probably spend more 
time on this soon. In particular adding support for PDO mapping.



Regards Nicklas Karlsson



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

Re: [Emc-users] Another Mesa vhdl question (STMBL summary with added pico-pi?)

[Chris Albertson]

On Fri, Jan 22, 2021 at 1:42 PM Ralph Stirling <
ralph.stirl...@wallawalla.edu> wrote:

> I don't think you are going to use an ADS1256 for
> servo feedback.  30khz sounds good, but when you
> look at the datasheet fine print, there are caveats.
> First, the inputs are multiplexed, so cycling the
> multiplexer drops your 30khz data rate to an effective
> 4.3khz rate.  There is also a 0.2msec settling time
> for the digital filter (which would be per channel).
> I'm not sure how much it affects CNC control, but
> I know in robotics applications non-simultaneous
> sampling causes problems.  The sequential multiplexing
> causes each axis to be sampled at a different time.
>

With robots, the way this is fixed is that the ROS "TF" or geometry
transform messages are timestamped.   Then the TF package can interpolate
the transform for any desired time.  So if say you have an arm with 6
joints and each sensor is sampled at different rates it still works.   THis
works because the parts have mass and can't teleport instantly to random
places.  so you can compute the position of the "fingers" even if all the
joints are sampled at random times.   The TF package hides all this

Basically if you know the transfom at any two points in time then you can
estimate the transform at any point in time near those two measured
points.  And again, this is all hidden inside the infrastructure.

I say "transform" because in general even though mostly we use rotation
(angle) only it might be any kind of linear transform.   Yes it is a lot of
real-time math but 16-core Xeon computers are cheap now.

>
> A precision single-turn pot for a linear axis sounds
> like a problem for other reasons.  You would have a
> giant discontinuity every revolution.
>
> Anyway, this ADS1256 on these Chinese cards does
> look very interesting for other, non-realtime applications.
>
> -- Ralph
>
> 
> From: Gene Heskett [ghesk...@shentel.net]
> Sent: Friday, January 22, 2021 12:45 PM
> To: emc-users@lists.sourceforge.net
> Subject: Re: [Emc-users] Another Mesa vhdl question (STMBL summary with
> added pico-pi?)
>
> On Friday 22 January 2021 14:37:56 andy pugh wrote:
>
> > On Fri, 22 Jan 2021 at 18:41, Gene Heskett 
> wrote:
> > > What comparison can be made between the very limited, fixed scale
> > > A-D conversion of a mesa card's 1st 4 inputs on say a 7i76, and the
> > > A/D speed and scaling that $4 pico-pi might be able to do when
> > > running the STMBL code, and how fast could it do it?
> >
> > If you want lots of high resolution A to D, have a look for ADS1256
> > boards on eBay.
>
> That's a sweet price for that much precision, and 30ksps sounds like its
> plenty fast enough to run a servo feedback from precision pots. Good
> thing about the precision being 24 bits, as the max of 3 volts full
> scale says it will need scaled at the inputs to live with 5 volt or
> higher circuits. With an SPI interface, working that out to cohabit with
> a 7i90 looks to be an interesting project. And I just ordered a 4
> channel digital scope so I can see this stuff better. A 2GS input gets
> pricey though.
>
> Thanks Andy.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeneslinuxbox.net%3A6309%2Fgenedata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7b16a513d0b74475828608d8bf16aa15%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637469451362247427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=DjcpC5qnBuyCYsgQU71FG8kTK7DNym23XrYlK277ItQ%3Dreserved=0
> >
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7b16a513d0b74475828608d8bf16aa15%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637469451362247427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a20RBPKaM0pedhfPRU4R6WsbazAyJpUMdYABIiImbs8%3Dreserved=0
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

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