Re: [Machinekit] Bamboo cnc/limit switch errors

[Chris Albertson]

only on the ends, but we have been able to successfully cut this
>>> dimension previously (on a 3-axis Techno machine).
>>>
>>>
>>> On Tuesday, July 21, 2020 at 1:12:01 PM UTC-4 blaz...@gmail.com wrote:
>>>
>>>> You didnt mention what type of limit switches you're using or how your
>>>> spindle works. The Y axis itself shouldn't be under any special stress
>>>> while cutting but the spindle generally takes a hard hit as soon as a tool
>>>> enters the cut. Is the spindle motor powered by the same power supply your
>>>> switches are on? Supply could be dropping low. Is the machine not ridgid
>>>> and vibration tripping the switches?
>>>>
>>>> On Tue, Jul 21, 2020, 8:54 AM Mason Millner  wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We are developing a 4-axis CNC to mill bamboo poles and are currently
>>>>> running tests in just three axis (x, y, z). We can dry-run g-code files
>>>>> successfully, however we receive limit switch errors (primarily on joint 
>>>>> 1)
>>>>> when we begin cutting material. We suspect that the error is occuring in
>>>>> the y-axis and that possibly our drivers are causing a problem (either 
>>>>> they
>>>>> are too small or not tuned adequately).. It is difficult to tell what is
>>>>> going on and how the machine is configured from the information given.
>>>>>
>>>>>  We have the z-axis running on the long x-axis, running on two shorter
>>>>> dual y-axes.
>>>>>
>>>>> The axis shaft is a ½” (12.7mm) , also the motor shaft is ¼”
>>>>> (6.35mm).  we are using polyurethane insert couplers (these have regularly
>>>>> been coming loose though).
>>>>>
>>>>> The motors are NEMA 23s with  3A rating/phase controlled by Pololu
>>>>> TB67S249FTG drivers on a Cramps 2.2 cape on the Beaglebone Black. The
>>>>> drivers have a current limit of 1.6A and are further limited to %90 for
>>>>> safety. The Current limit for the board and drivers are defiantly a bottle
>>>>> neck, but the motors have enough power to operate. [Could this be the
>>>>> problem?]
>>>>>
>>>>> Any help or recommendations would be greatly appreciated. If more
>>>>> information is needed please let me know. I'm fairly new to the machine
>>>>> development side of this project. Thanks.
>>>>>
>>>> --
>>>>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>>>>> github: https://github.com/machinekit
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Machinekit" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to machinekit+...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/machinekit/790379d8-160b-4fed-9fa2-d03cbe160926n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/machinekit/790379d8-160b-4fed-9fa2-d03cbe160926n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>>> github: https://github.com/machinekit
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Machinekit" group.
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to machi...@googlegroups.com.
>>>
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/machinekit/8c6cb16c-03d6-4c1c-8cc5-0d8ad5012849n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/machinekit/8c6cb16c-03d6-4c1c-8cc5-0d8ad5012849n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/d050bf01-401b-4d4d-8c1a-e75efff04695n%40googlegroups.com
> <https://groups.google.com/d/msgid/machinekit/d050bf01-401b-4d4d-8c1a-e75efff04695n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHsLnK9mtJ4Br4t%2BFus%3DB0pqUp8AruGOB7hKKy_iyuG6dQ%40mail.gmail.com.

Re: [Machinekit] Sending gcode to Machinekit from remote source

[Chris Albertson]

My first thought is that way can't you open a named UNIX pipe and read
g-code from it just as you read from a disk file.  Then the process that
writes to the pipe can get the g-code any way it likes from any remote
location.   See the man page for "mkfifo" if you've not used named pipes
before.   It should work with no modifications to MK.


On Tue, Jun 16, 2020 at 9:33 PM Michael Labuda 
wrote:

> Greetings fellow Machinekit users,
>
> I am wondering if Machinekit has any method of remotely receiving gcode
> commands from another application, similar to MDI mode except code is not
> typed directly at the UI. I am not concerned about security or latency and
> the gcode instructions I intend to send over are very simple, just G00/G01
> and an occasional M code. I have found some unresolved posts asking a
> similar question however they are all several years old. Has such a
> capability been added on since then? Could someone point me in the best
> direction in which to implement such an option? I am open to developing a
> solution myself is necessary. Any advice would be greatly appreciated.
>
> Thanks,
> Michael
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/0a67eaea-755a-4cb1-87c9-d82789169d06o%40googlegroups.com
> <https://groups.google.com/d/msgid/machinekit/0a67eaea-755a-4cb1-87c9-d82789169d06o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHs-m3dCz-ffkFGMsfcL-oXjO%3Dzm9yzE%3D6qLgkPnbiHBsg%40mail.gmail.com.

Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Chris Albertson]

alte Schmidt wrote:
>>>>
>>>> I think the issue is always that the requirements with these machines
>>>> are very different and that you never quite get what is needed.
>>>>
>>>> When I build the cape I use on my lathe I sort of used a modular
>>>> design. I based this on a prototype cape and used those small optocoupler
>>>> and level shift modules that you get from China for the maker scene. It
>>>> looks quite like a hack but you might see the three opto modules in the
>>>> back and the two level shifters here:
>>>> https://forum.zerspanungsbude.net/download/file.php?id=188366&mode=view
>>>> There is an external pwm-> 0-10V module as well (not shown) for spindle
>>>> control
>>>>
>>>> I always thought about making this nicer. I would have done it this way:
>>>> A cape that:
>>>> - Make PRU and GPIO Pins available in sets of 4? pins on standardized
>>>> PIN headers + power.
>>>> - Makes the terminals for connecting the cables available
>>>>
>>>> PLUS
>>>>
>>>> Small modules for level shift, opto isolation , spindle control (as
>>>> desired). These would use the standardized connectors on the cape.
>>>> For this I would actually rely on stuff that is already available (if
>>>> so).
>>>>
>>>> --
>>> website: http://www.machinekit.io blog: http://blog.machinekit.io
>>> github: https://github.com/machinekit
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Machinekit" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to machi...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/machinekit/4e75a7ba-b13f-4579-a7f1-09211ff4cbd7o%40googlegroups.com
>>> <https://groups.google.com/d/msgid/machinekit/4e75a7ba-b13f-4579-a7f1-09211ff4cbd7o%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/61c7c2b7-e1bb-4c2c-8556-355bf16645b2o%40googlegroups.com
> <https://groups.google.com/d/msgid/machinekit/61c7c2b7-e1bb-4c2c-8556-355bf16645b2o%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/E3597AE0-5791-438A-981D-D941017C7FB3%40basdebruijn.com
> <https://groups.google.com/d/msgid/machinekit/E3597AE0-5791-438A-981D-D941017C7FB3%40basdebruijn.com?utm_medium=email&utm_source=footer>
> .
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHty0M01OoS-Vke91nF6L%2BEhd3zEvyiEVdQcd2s%2B3_e15g%40mail.gmail.com.

[Machinekit] AC power supply for stepper driver?

[Chris Albertson]

Is anyone using an AC power supply for their stepper motor driver?

I'm looking at using this motor and driver and see that it accepts either
AC or DC power.   It reads "Input Voltage: 20~80VAC/30~110VDC"  So it seems
like all I would need is a 60 VAC transformer.Has anyone done this?
  Is there one type of transformer that works best?

stepperonline.com/closed-loop-stepper-kit/ye-series-1-axis-closed-loop-stepper-cnc-kit...
<https://www.omc-stepperonline.com/closed-loop-stepper-kit/ye-series-1-axis-closed-loop-stepper-cnc-kit-12-0-nm-1699-68oz-in-nema-34-motor-and-driver.html>
-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHvvr6vdU%3DOhdjw3mzfn59-dnqW145KbCgM7kSgAzcj-jg%40mail.gmail.com.

Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Chris Albertson]

>
> Isn’t that something the Beagle is strong at with the eQEP and PRUs?
>


Strong only until you hit up against the limited number of I/O pins.  A PRU
based solution is cheap and simple but can't scale.

In general TI's idea to place a small microcontroller on the same chip as
their ARM Cortex-A was good and we see others doing this too but a big
machine tool like a 5-axis mill with tool changer and cooling and saftey
interconnects is going to need something bigger than a PRU.  FPGAs work
well as wold an STM32 tht had on order about 100 pins.

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHs5uknWtEY-sP-hxfb13LNZ8CWBxxK30TiBn%3DOQ820K%2BA%40mail.gmail.com.

Re: [Machinekit] Re: Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Chris Albertson]

I doubt you'd want any kind of motor drivers on the board.   The board
would have logic level outputs only and would interface to
industry-standard motor drivers that run off step/direction or 0 to 10
volts or even Ethercat.

This is where the board gets larger and expensive as it would need to
support 3 or 5 different kinds of interfaces for 5 or 6 axis.But the
hope is that mas producing one PCB is cheaper than making five different
variation


Also,... If these are a true "Open Source" design then we users would
send the Geber file to a PCB fab in China and have 3 to 5 PCBs made then
solder down only the parts we need.Those only using step/direction woud
not bother to buy or solder down the analog or Ethercat chips. and
connectors.

On Thu, Mar 12, 2020 at 12:19 PM Mala Dies  wrote:

> Hello,
>
> I erased my last message. I think my last message was just reaching out.
> Here:
>
>
>- What are we talking about in regards to the power consumption of the
>available wattage?
>   - 125w
>   - 150w
>   - 175w
>   - etc...
>- I am asking b/c some motors will drive that much wattage by
>themselves.
>- I am missing something as usual.
>   - Would we power the board, AI, separately?
>   - Are the pins already available on the AI for use without .dts
>   files?
>  - If not, can we expect a config-pin source to work in the
>  future?
>  - Or, are we going to have to deal with EEPROM already
>  "registered?"
>
> I have these subtle questions because I am all in on this idea. I do not
> care for the AI handling the GUI. I would rather my chromebook or laptop
> handle it.
>
> Can I expect to handle more than three, 100w brushless stepper motors?
>
> Seth
>
> P.S. I will have a million more questions available by the time I post
> next. I am being nosey on purpose. I want to know things. I especially want
> to know what type of motors I can handle on this Cape. Are people already
> handling design, a wiki, and/or status updates on this venture?
>
>
>
>
>
>
>> Seeed is looking to not only build a Machinekit-focused Cape for
>> BeagleBone Black and BeagleBone AI, but to:
>> * Take in features and feedback from the community
>> * Contribute the design to open source and certify it as such
>> * Manufacture the design under the BeagleBoard.org name to support the
>> BeagleBoard.org Foundation and community
>> * Help assemble and provide software images configured for an open source
>> 3D printer and CNC machine (with BeagleBoard.org and community guidance and
>> support)
>> * Offer a collection of additional accessories which might commonly be
>> needed
>>
>> I am very excited about this because I know Seeed cares about open
>> hardware and also knows how to deliver solutions reliably and cost
>> effectively.
>>
>> So, what are your ideas about where to start on such a cape?
>> --
>> https://beagleboard.org/about
>>
>
> On Thursday, March 12, 2020 at 8:38:53 AM UTC-5, Jason Kridner wrote:
>>
>> Seeed is looking to not only build a Machinekit-focused Cape for
>> BeagleBone Black and BeagleBone AI, but to:
>> * Take in features and feedback from the community
>> * Contribute the design to open source and certify it as such
>> * Manufacture the design under the BeagleBoard.org name to support the
>> BeagleBoard.org Foundation and community
>> * Help assemble and provide software images configured for an open source
>> 3D printer and CNC machine (with BeagleBoard.org and community guidance and
>> support)
>> * Offer a collection of additional accessories which might commonly be
>> needed
>>
>> I am very excited about this because I know Seeed cares about open
>> hardware and also knows how to deliver solutions reliably and cost
>> effectively.
>>
>> So, what are your ideas about where to start on such a cape?
>> --
>> https://beagleboard.org/about
>>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/73cb20b7-83ba-4b8f-a629-3127cb5d16bf%40googlegroups.com
> <https://groups.google.com/d/msgid/machinekit/73cb20b7-83ba-4b8f-a629-3127cb5d16bf%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 

Chri

Re: [Machinekit] Seeed to design and build Machinekit focused Cape for BeagleBone Black/AI

[Chris Albertson]

On Thu, Mar 12, 2020 at 11:47 AM Jason Kridner  wrote:

> If you are putting a fast processor on the main board, what is the Beagle
> doing?
>

The Beagle is running the servo loop, g-code interpeter, motion planning,
and the user interface.  Step-gen and quadrature decoding are done on the
hardware.Pretty much exactly that way it works if you use a PC and a
Mesa FPGA card.


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHvDN-Ajma07v_VgAE9LZvj0Fd%3D53rxUN8XgVwbL9%2BXynw%40mail.gmail.com.

Re: [Machinekit] Re: PICnc with Machine Kit.

[Chris Albertson]

Yes, for a long time to come if you buy an industrial PC it can have
lagacy interfaces on it like USB2, Ethernet and maybe even RS232 or
Parallel ports.  But if you have an "ordinary" PC you got at Best Buy, in a
few years they will be 100% USB-C and you will need a dongle to connect the
older ports.

That said even the idea of using a PC is getting old.  People today use
phones and tablets, mostly phones and don't want wires of ay kind.Yes,
of course, those industrial PCs will have wires but look at today's
higher-end PC, I don't even see USB connected keyboards except at the low
price points

Today WiFi can be much faster then even gigabit Eithernet.  The new 5G
networks will also be faster than Eithernet.A basic cell phone will be
much more capable than a PC was only 6 or 8 years ago.

In terms of market share LinuxCNC/EMC does not even show up.  It is nearly
zero.

The way to think about a new-start product is to look at the workflow.
 Engineers will likley always work at computers with large screens and 3D
modelsing CAD systems.   Their work product goes into some kind of version
control system that tracks versions and comments and problems.  Then the
CAD design gets converted to g-code and also version controlled ad then
some sign-offs maybe.   Finally, there is a machine tool.  I thik all users
want is to be able to point the machine to a version controled g-code file,
set up the stock on clamps and "go".

On Sun, Mar 1, 2020 at 2:09 PM cern via Machinekit <
machinekit@googlegroups.com> wrote:

> Guys, please, make sure that you click "Reply to all" and that you include
> the machinekit@googlegroups.com address in the "To" form.
>
> Thanks,
> Cern.
>
>
> Mar 1, 2020, 22:53 by jo...@autoartisans.com:
>
> > Personally I think that's a load of crap.  One only has to look at the
> various microprocessor products out there to see that USB 2.0 as an
> interface will be with us for a very long time.  One of my clients switched
> from using Panasonic Tough Books for their PC interface in their product to
> the dedicated industrial PC boxes.   And their products are designed to
> have at least a 10 year life.   And those boxes will have USB 2.0 for a
> long time along with Ethernet.
> >
> > Take a look out at the industry where suppliers and manufacturers are
> attempting to alleviate their clients fears about buying a specific
> technology so they promise at least a 10 year life span.  I'm still using a
> 9S12 series in a product that as yet has not been issued an end of life buy
> request.
> >
> > Of course newer PCs will come out with USB-C.  Of course over the years
> we will see products that are sold with that.  And we'll probably also see
> a ton of products that are the USB-C connection to the laptop and have 4 to
> 8 USB 2.0 connectors to attach to all the real hardware that's out there.
> >
> > So yes we will see new embedded processors with USB-C.  Of course.  But
> to say that the only design choice is that is ignoring what is already
> there.
> >
> > John
> >
> >
> >> -Original Message-
> >> From: cern via Machinekit [mailto:machinekit@googlegroups.com]
> >> Sent: March-01-20 1:26 PM
> >> To: Chris Albertson; Machinekit
> >> Subject: Re: [Machinekit] Re: PICnc with Machine Kit.
> >>
> >> Hi,
> >> the original author didn't include the 
> email
> >> in his reply, so I am posting this as an all-in-one answer.
> >>
> >> Mar 1, 2020, 06:20 by albertson.ch...@gmail.com:
> >>
> >> >
> >> >
> >> > On Sat, Feb 29, 2020 at 4:27 PM cern via Machinekit <>
> >> machinekit@googlegroups.com> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >>  I am all in for cheap, low entry hardware. Don't care if it is PIC
> or ARM. I
> >> think that for most cases it would be enough to have just serial
> connection
> >> between PC/SBC and this board. But some simple� Ethernet based
> >> communication�
> >> >>
> >> >
> >> > In today"s world and tomorrow's world, the only serial interface that
> makes
> >> sense in a new design is USB-C.� This goes duble if it has to connect
> to a PC. �
> >> Soon this will be the only data connector PCs have. � � What is quickly
> >> becomming�universal is USB 3.1 protocol�over a USB-C connector. � � It
> can
> >> do 10 Gigabits persecond. � But just as importantly�it can be VERY low
> >> latency with�> isochronous transfers and there are specs for buffer
> times on
> >> hubs. � ��>

Re: [Machinekit] Machinekit lathe gcode not working as expected

[Chris Albertson]

Two numbers stand out 45mm and 90mm. Notice that 90mm is exactly twice
45.A common mistake is to forget that moving the tool 1mm reduces the
diameter by 2mm.  Diameter is twice the tool movement. g-code specified
tool movement, not part size   Getting this backward might explain the 45
and 90 error.

On Thu, May 30, 2019 at 11:40 AM Gediminas Dirma 
wrote:

> Hello,
>
> I am running CNC lathe with beaglebone and machinekit.  Lets say that i
> turn down cylinder from 45mm to 40mm. In my CAM i generate gcode and it
> seems fine.
> But then i upload it to machinekit, it changes turning diameter it then
> starts turning not from 45mm but from 90mm and it turns down 5mm. It seemes
> that something
> is with X axis, since Z is working fine. What could cause this problem?
> Maybe I do something wrong with tool table but i followed procedures writen
> here http://linuxcnc.org/docs/html/lathe/lathe-user.html
>
> Thanks for help.
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/machinekit/30e422e8-c824-4f50-9636-f1a2c6681967%40googlegroups.com
> <https://groups.google.com/d/msgid/machinekit/30e422e8-c824-4f50-9636-f1a2c6681967%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/machinekit/CABbxVHvUaFDsayG_5ZZd5vg435uvmrM4z3vh7phEZ1MoKk8F%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] PRU PWM reader implementation - asking for feedback/suggestion

[Chris Albertson]

Chris Albertson
12:28 PM (0 minutes ago)
to Damien
In general, the way I'd read a PWM input signal is to measure the length of
the high and the length of the low parts independently.Almost all small
CPUs now days have external hardware that you can program to measure pulses
then in software you can read the pulse lengths after each pulse.  You need
two timer  channels, one to read the low and one to read the high.
After every two pulses (one high, one low) you have a fraction and then can
convert to floating point or whatever you need.Typically you get to
choose the counter rate and so get any resolution you need.  Set it as fast
as you can but not so fast that a 90% duty cycle would overflow the 16-bit
counter.

The details of how to do this depend on the exact chip so few people bother
stuffing registers and instead use the manufacture's PWM library function.

30 years ago processors just had simple digital pins and everything had to
be done in software.  Today even the $1 uP chips have just tons of
peripheral hardware, so you can do things like read A/B quadrature or
generate PWM with on-chip hardware.   My experience is mostly with STM32
but TI works as well and TI has a software development kit.  Anyone using
TI chips needs to know TI's SDK. then just use their PWM input function.

On Tue, Feb 26, 2019 at 11:33 AM Damien Dando  wrote:

> In response to
> https://groups.google.com/forum/#!topic/machinekit/5TIA7b-7Q1k
> Note: I'm trying to create a new post to answer because for some unknown
> reason google keep deleting my answer right after I post it in the original
> thread. I also tried to leave Machinekit group to re-join hoping it would
> reset something but no luck.. fuck google! If anyone known how to solve
> that let me know.
>
> Thanks Charles!
>
> In the end I did recompile the all Machinekit on BBB, took a while but it
> eventually worked and I got the dev. env. working now.
>
> You may also want to look at the timer/capture modules, both in the
>> ARM system (with Linux drivers) and there's one module within the PRU
>> domain.  You can use these to time pulses and you will get several
>> orders of magnitude better accuracy (~10 nS) vs. trying to monitor the
>> signal with PRU software (~1-10 uS), but that may or may not be
>> important depending on the PWM frequency range.
>
> 10uS is already overkill for my needs ;)
> I'm reading feedback signal from ClearPath motors
> <https://www.google.com/url?q=https%3A%2F%2Fwww.teknic.com%2Fproducts%2Fclearpath-brushless-dc-servo-motors%2F&sa=D&sntz=1&usg=AFQjCNEvOk7R_8YKWL7kTygoqgTooMdbWA>
>  and
> the PWM frequency is only 50Hz. Also I'm using regular GPIO inputs because
> there is too much constraint with dedicated PRU inputs pinout.
> Since I saw quite few video with people using those same ClearPath motors
> <https://www.teknic.com/products/clearpath-brushless-dc-servo-motors/> on
> their CNC, I'm sure many would benefit from having this feature in
> Machinekit.
>
> Also I would be happy to contribute to Machinekit project so I was
> wondering what are requirements/process to add a feature/push request to
> Machinekit official source code.
>
> In order to integrate it at best into Machinekit source code, that would
> be great to have feedback on some question:
> @Charles: As it seem you have done a lot of work in the hal_pru_generic
> driver, your feedback would be valuable&appreciated :)
>
> Since I'm not using dedicated PRU inputs, reading a regular GPIO input pin
> takes ~170ns (~190ns for GPIO bank 0). For this reason, I aim to read GPIO
> bank(s) not more that once per pru period and only if needed.
>
> I see 2ways of doing that:
>
>1. read GPIO inputs "globally" (in similar way as it is done for GPIO
>outputs in pru_wait.p
>
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fmachinekit%2Fmachinekit%2Fblob%2Fmaster%2Fsrc%2Fhal%2Fdrivers%2Fhal_pru_generic%2Fpru_wait.p%23L204&sa=D&sntz=1&usg=AFQjCNGBlHA8xVFFCtUPIZQH1MTHfStebA>).
>This requires to add some code in pru_wait.p
>
> <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_wait.p>
> and/or pru_generic.p
>
> <https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p>
>  and
>therefore extends a bit the overall pru period. The major advantage is that
>it would allow any others hal pru "modules" to use any GPIO inputs (the hal
>pru encoder could then be updated to work also with regular GPIO inputs).
>2. read GPIO inputs "locally" in the PWM reader pru task I'm
>implementing. The drawback we will need to re-read GP

Re: [Machinekit] Rotary CNC + Bamboo + BBB + CRAMPS?

[Chris Albertson]

>
> *I* am not using vision for anything at the moment, so I'm assuming
> you're asking the original poster.  I'm not sure what they have
> planned for vision, but I'd be interested in hearing more details
> about it as well.
>

I did ask him, The answer was a little confusing.They use vision to
measure the bamboo then put this information into a model in Fusion 360 and
then output standard g-code to drive the mill.   So the vision task is
complete before the g-code is written and they don't run the mill and the
vision at the same time.

The confusing part is that if they are running Fusion 360, they have a
high-end PC or Mac available.  If it can run Fusion, it can run any vision
software they would need.



> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Rotary CNC + Bamboo + BBB + CRAMPS?

[Chris Albertson]

On Tue, Feb 26, 2019 at 12:31 PM Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> Please keep replies on-list.
>

Sorry, I intended to.

>
> For pick-and-place, there are a few open-source projects working on
> solving the problem, such as OpenPNP:
>


The problem is not just wanting a PnP machine but wanting to learn to use
MK for a wider range of machines.Yes that is one solution, getting MK
to read g-code from a pipe or socket and then some process to feed the pipe
in real time.

I'm still wanting to know what you are goin to use the AI/Vision hardware
for.



> http://openpnp.org/
>
> Often, the "back-end" performing the motion does use gcode.
>
> On 2/26/2019 2:01 PM, Chris Albertson wrote:
> > I just read the TI's paper on this.   They describe the workflow for
> using
> > the machine learning and vision subsystem.  And the workflow is not
> > super-horrible as I feared.  It fact it seems straight forward if you are
> > already familiar with machine learning and vision.   For others, the
> > 15-second summary is this:
> >
> > You develop your machine learning or vision system on high-end PC
> hardware
> >> (at least a nVidida GTX10XX GPU)  under Linux.  You use familiar tools
> like
> >> TensorFlow and openCV.Then there is TI software that takes what you
> >> have running on the PC and translates it to run on the much smaller
> device
> >> on the Beagle Board.   The beagle is about 100x slower but speed is
> really
> >> only needed for training a network, not needed to run it.
> >
> >
> > For those not in the field. "Machine Learning" is almost a misnomer.  The
> > training and learning happens on the big PC then we "freeze" a snapshot
> and
> > move it the tiny chip where it never leans or changes behavior .  The
> > learning happens only in the lab.
> >
> >
> > Nowhere is my question:  The most simple use case of this that relates to
> > Machine Kit is a pick and place machine.  This is a 2-axis machine that
> > picks up a tiny part from a surface and drops it some other place on the
> > surface.  It does not even have a true z-axis.   But the catch is finding
> > the part and finding the *exact* place to drop the part.  For that we
> need
> > a camera.   No-one uses g-code for these machines because we can't know
> in
> > advance how the machine is to move.  So what we do is tell the machine
> > where the parts are in general and where relative to the final assembly
> the
> > part should go.
> >
> > It seems to me this machine would replace the g-code interpreter with
> > different logic but otherwise could work exactly the same.   Or perhaps
> the
> > g-code is not read from file but there is a process that generates it in
> > real time based on the camera.
> >
> > What I'd like is to use my Harbor Freight Mili mill as a picking place
> > machine.   This would be REALLY popular., simply place a little vacuum
> > picker on the spindle and for very little cost you have a slow slow pick
> > and place machine suitable for hobby level PCB assembly.   The HF mill
> > should be accurate enough.
> >
> > In any case, how were you planning to this vision and machine learning
> > hardware to MK?
> >
> >
> > On Tue, Feb 26, 2019 at 8:15 AM Charles Steinkuehler <
> > char...@steinkuehler.net> wrote:
> >
> >> FYI:
> >> The BeagleBone-AI may be a good fit for your project:
> >>
> >>
> >>
> https://www.facebook.com/photo.php?fbid=10218976824519992&set=a.2907631578284&type=3&theater
> >>
> >> It should do machine vision _much_ better than the BBB.  It's
> >> basically the SoC from the X15 in a BeagleBone form factor.  I'm
> >> working on getting Machinekit working on this board and verifying
> >> capes work as expected.
> >>
>
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Lathe tailstock axis

[Chris Albertson]

Is this a conventional lathe?   If so I thought that only had two axis "X"
and "Z".

But maybe you are talking about a motorized tailstock?  If so, I'd treat it
more like a tool changer than an axis.  It moves with a M-code.

On Sun, Feb 10, 2019 at 11:40 AM Gediminas Dirma 
wrote:

> Hello,
>
> I am making lathe with machinekit and beaglebone. I have made
> configuration for all axis except tailstock. I have a hard time to
> understand what changes a should make in ini and hal file. I believe
> changes should be made in traj section but its not clear to what parameters
> i should change my values.
>
> Thanks for help
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Beagle Bone Black IO Expander Question

[Chris Albertson]

You can buy SPI interface parallel ports with 16-pins per chip.   It's a
single chip solution for what you are doing and it connects directly to the
SPI pins on the ARM processor   The Microchip MCP23S17 is one example.

The Max MAX7301 is nice too.  You get 28-pins and each is programable
 input of output and  yo can turn on an internal pull up.  Works up to 5.5
volts and handles data at 20+ MHz.   This is also a one chip solution.
There are a lot of them out there.  Those shif registers are from the 1980's

On Mon, Jan 14, 2019 at 1:13 PM Dave  wrote:

> Hi,
> I am working on a cape for basic IO buffering for the step/dir pins and I
> also want to use shift registers for the regular input/output.
> I am planning on using a 74hc595 on the board for the 8 outputs and a
> 74hc165 for the inputs.
>
> --

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Support for new BeagleBoard.org hardware

[Chris Albertson]

What would that new Beagle be called?The "PocketBeagle"  looks very
interesting.  Not only does it have the two PRUs but also an M3.

On Fri, Dec 28, 2018 at 12:20 PM Jason Kridner  wrote:

> I’m looking for a volunteer for putting Machinekit on nee BeagleBoard.org
> hardware in exchange for early access. Anyone interested? Have the needed
> skills?
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] GUI Geared towards Embedded Platforms

[Chris Albertson]

One question about a GUI that draws to the frame buffer:   How do you share
the screen with other software?  Here is a scenario.   You boot the machine
and I guess you get to the command like X11 is not started,  Next you run
the special version of MK that has the buffer writing GUI and you see the
program start and then write to the screen.But now you want to copy a
G-Code file over the network.  How do you start a terminal window?   I
assume you'd need a second computer or an iPad and login in via ssh.

I've had the same problem, you have a tiny micro controller, smaller even
then a Raspberry Pi and you want to put up a display but the computer lacks
hardware.   In those casesI like to use HTTP.  Basically  I build a tiny
micro-size web server in to the device.Most WiFi routers do this and
many ink jet or laser printers too.  The user sets them up using a web
browser.

On Sat, Sep 22, 2018 at 11:10 PM schoone...@gmail.com 
wrote:

> HI Travis,
>
> I will be interested to have a look at this later.
>
> The includes you want should be in the flavor package
>
>
> https://github.com/machinekit/machinekit/blob/master/debian/machinekit-rt-preempt.install.in#L4
>
> We don't have a -dev package and each kernel has a specific sub package
> which also contains the includes etc.
>
> I suspect you may have just installed machinekit, whereas you need 'apt
> install machinekit machinekit rt-preempt' for instance.
>
> I will check the package contents later, but see no reason why those would
> be missing.
>
> regards
>
> On 9/22/2018 8:07 PM, Travis Gillin wrote:
>
> I'm working on a GUI that's meant for embedded applications with fairly
> low resources. It's C and C++ based and runs entirely without X, deals
> directly with the framebuffer and evdev for mouse & keyboard. (Touchscreen
> also supported)
>
> I have a post here about it
> https://forum.linuxcnc.org/41-guis/35225-new-gui-for-embedded-systems. I
> posted here to figure out how to talk to LinuxCNC via C (libNML) and this
> has all been figured out most part. My trouble now is when I try to build
> against machinekit, there is no /usr/include/linuxcnc. (or
> /usr/include/machinekit either) Specifically I need "" &
> "" equivalents for MachineKit. I know this project was
> forked a while ago but I believe the NML interface is the same.  Could
> someone here point me in the right direction?
>
> Right now the GUI runs on LinuxCNC on a regular Intel-based PC just fine
> and the only hang-up in migrating to our ARM platform is this little
> difference between LinuxCNC and Machinekit.
>
> I think this GUI will be a great addition to this project because it will
> allow people to use HDMI or virtually any type of display from Beagle Bone,
> Rasp Pi, or other embedded devices that Machinekit has been ported too and
> not have the "click and wait" lag.
>
> Thanks,
> Travis
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Connecting HAL components across multiple CPUs

[Chris Albertson]

485, ethernet, etc.)  Is there
>> something out there that does this?  Maybe some kind of mutant hybrid
>> between HAL/NML/SCADA?
>>
>> Of course this complicates things over simply using pointers to a single
>> shared memory space.  I also get the sense the linuxCNC group balks at this
>> kind of idea, they want to keep it all on one machine in the interest of
>> latency anyway.  Just searching various machine controller project
>> communities for where this kind of idea might be interesting.  I would
>> really like something like a Raspberry Pi tied into a MCU which does all
>> the hard-RT/IO stuff, but not quite in the way Klipper does it.  Klipper
>> basically sends commands to be followed at some specific time stamp.
>> That's actually pretty cool, but I want something that allows for more
>> feedback and flexibility between the various systems.
>>
>> Anyhow, thanks in advance for your input.
>>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit]

[Chris Albertson]

Is anyone using a CNC mill to make PCBs?  The video linked below shows
someone doing this on a small mill with Mach 3.  The PCB is certainly not
high tech.  The parts are all through hole with 0.1 inch lead pitch and it
is one side only.  Right out of the 1970's but it is exactly what I want to
make.   More complex PCBs can go to oshpark

Is there a Linux based tool chain?   The part I don't see is how to convert
Gerber files to g-code files.

Then what tools work best?  I think three are needed tiny end mill to route
copper, Tiny spiral mill for cutting the PCB all the way through and a few
micro side drill bits for the through holes.

BTW it seems like the guy in the video could have saved a lot of time by
using a (fake) ground plane that flooded all the empty space.  No need to
mill all that copper away.

https://youtu.be/xM8sTEw3OLQ?t=5m41s

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] LinuxCNC and BeagleBone Black - a road well travelled?

[Chris Albertson]

On
> Beaglebone specifics notwithstanding, the documentation is still lacking. 
> Your explanation is the same one given by every open source project that 
> lacks documentation. No one wants to do it (some, like swift.org, are 
> excellent, but it's backed by an organization with deep pockets and it pays 
> people to work on it). But that doesn't change the fact that it's lacking.

Yes, I notice the same trend.  The open source projects that have
actual budgets and corporate funding tend to have better
documentation.

One thing that might help is to lower the barrier to contributors.
Put the docs on a Wiki.


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] VCarve "gcode sender"

[Chris Albertson]

I just asked this same question.   I wanted to do it for a different
reason.  I want to make a hand held CNC controller that sends g-code over a
serial link.  The answer is (some one will correct me if I'm wrong) "It can
be done but not out of the box"

But in your case I don't think you want to do what you describe because the
PC would have to keep the "print" job running until the CNC machine was
done.  Better I think if the file zaps over at high sped, the PC "thinks'
it is done and then the CNC machine goes on making the part.

If you want this to look like a printer then run a print server on the
Linux Machinekit machine and it will queue the print job on the Linux side.
  It is not hard to set up.  No reason not to queue up CNC jobs using the
standard UNIX print queue system.  It should work.

BTW, the 3D printer ecosystem has me spoiled.  There We can run a central
job manager that connects to multiple printers and we can sign jobs to
printers and monitor progress using a web cam.  There are a few good ideas
worth borrowing.

On Thu, Mar 1, 2018 at 9:15 PM, Richard Thornton 
wrote:

> Hi All,
>
> Is it possible to "Output Direct to Machine" can machinekit accept
> instructions from something like VCarve over the network, so you
> design in VCarve and from the same windows PC print to the machinekit
> (CNC)?
>
> Thanks.
>
> Richard
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] mach3 interface board 5 axis

[Chris Albertson]

Can the optocoupler be driven with 3.3 volts?  I don't know.  You'd have to
check.  The breakout boards are designed to be driven by the old style PC
printer port which were 5 volts

On Mon, Feb 26, 2018 at 1:30 PM, Andrij Senyk 
wrote:

> Hello,
>
> I have this one mach3 interface board 5 axis
> https://www.google.com/url?sa=i&rct=j&q=&esrc=s&source=
> images&cd=&cad=rja&uact=8&ved=2ahUKEwi25KzywsTZAhXKliwKHXBgA
> K0QjRx6BAgAEAY&url=https%3A%2F%2Fwww.aliexpress.com%
> 2Fitem%2FCNC-5-Axis-With-Optocoupler-Adapter-Stepper-
> Motor-Driver-MACH3-Interface-Board%2F1975186212.html&psig=
> AOvVaw2ExyVfNS9tou9jF77cLINW&ust=1519766863377451
>
> Its possible to connect to BBB without capes? That board have optocoupler.
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Can MK read g-code from serial port?

[Chris Albertson]

Is there an easy way to get MK to read g-code lines one at a time from a
serial port?  That means to read a code, then execute it right aways that
wait for another g-code.

The reason I ask is I was thinking the best way to make a hand help pendent
or controller is to have the controller send g-code.   It I won't to jog
and axis or do just about anything it can be sent over an 2 wire connection.

The controller I want to make will have a physical rotary encoder with 100
division and some push buttons and an LCD screen.  But I can envision doing
this also on an Android tablet.  The jog wheel and DRO are on screen.
 g-code seems the natural method of interface.

Marlin, the software that runs on most 3D printers does this.  It reads
g-code from a USB port, building a hand held controller for Marlin is
simple, just send g-codes.   I'd like to do the same with MK.  And use the
same hand controller for both


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Project suggestion

[Chris Albertson]

One more thing:   I looked up the atsame54 evaluation board.   It was $85
That is about $70 more than other comparable products.

Here is what I'm using:  http://www.st.com/.../nucleo-f401re.html

They are $12.74 if you buy them direct from ST Micro.  $15 at Digikey.

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Project suggestion

[Chris Albertson]

 reason behind all that is making a PLC where Rpi and MCU cooperate to
> manage complex interfaces (video, ethernet, usb) and the machine (fast PWM,
> analogic signal, and a big number of PIN), and it would solve a problem of
> the comunication between the two.
> I.e a thing like OpenPLC uses just readPin(pin) writePin(Pin, value) to
> manage the communication, so the MCU is simply a pin expansion, I think it
> can do more.
> One thing that I consider important is that the MCU could (given the right
> implementation...) be stand alone, so RPi could be rebooted or removed where
> not necessary (cheaper PLC where no video is requested)
>
> What do you think about all that? Does it make sense?
> Is there anything that I can / should use to avoid reinvent the wheel or to
> stick to an API?
> I am referring to protobuf, or any piece of Machinetalk. Anything that I
> should look before starting?
>
> Obviously all of this would work with BB instead of RPi, but there is no
> reason for having both MCU and PRU.
>
> Any question is welcome! This could be my graduating project, I will talk
> about it with the prof. in these days.
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Zynq uSD Image Generation

[Chris Albertson]

That makes more sense.  I read the specs and these will boot Linux from an
SD card.  You can download the image.   Then after that it looks like you
are building everything from source yourself.

If I were doing development on this little board I would put all the files
in my home directory on a NAS and share them over NFS to the development
board.  Running off an SD card is impossibly slow especially when doing
things like building kernel from source.

It is to bad these don't do a network boot, then you just keep everything
on the NAS and don't have to mess with SD cards.   But do put the home
directories on an NFS star.  I do that with all by Pi and eagle cards

I had a project that I thought might require an FPGA. It was controlling
four servo motors in a four wheel drive mobile robot.  Each  motor had it's
own encoder that could in the worst case make 11,000 pulses per second.   I
was going to put the PID loops inside an FPGA.   But them found out an Arm
cortex-4 at 100MHz could handle the interrupt rate.   Then I found that ARM
chips haver hardware quadrature decoding up to abuot 1MHz pulse rate so
they don't even use the CPU.   So I didn't use an FPGA.  But I was lookngat
his one. that are only $14 on eBay
https://www.amazon.com/EP2C5T144-Learning-System-Development-CycloneII/dp/B008B3YHE8



> Sorry, wrong link.  I mean the Arty Z7 with the dual-core ARM Cortex A9:
>
>
http://store.digilentinc.com/arty-z7-apsoc-zynq-7000-development-board-for-makers-and-hobbyists/
>


-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Is there any interest in a turnkey solution?

[Chris Albertson]

Ok, I see what you are doing.  More moments...

1) All those saying the interface needs to be in Windows.   No.  It just
needs to be exportable.   The display needs to be NOT linked physically to
the computer that turns the motors.People then can run the display
where they like.  Maybe on a tablet.   Maybe on a MacBook.  Maybe on a
Windows "surface" machine

2) Microsoft said this is the LAST version of windows.  "10" is it.   I
would not tie the long tern success of my business to Windows.  It will be
gone in 10 years.   OK not "gone" but VERY DIFFERENT. already we see things
like Windows 10S that can't run software not in the store.   Already we see
Microsoft moving to a rental model with other software and we see cloud
based services.   This is what is coming. after Windows.So please
re-read #1above. See it flexible, display decoupled and goes just
"wherever".Very, veery soon computers will by cloud connected devices
and software will be a subscription service and no one but ultra-geeks will
have what we call "windows PC towers".

3) You are going to need to build a controller that you can directly plug
motors into.   It is going to have to be a truly turn-key system, plug in
(1) Ethernet, (2) motors and (3) AC power and that's it, end user assembly
is just four wires..  If you required more from the end user you will waste
endless  paying you army of technical support specialists to debug poor
filter connections.   You want to sell a closed box

4) if the user has to know that there is an operating system inside, it is
to hard to use.  My Ink jet printer runs Linux inside but very few users
know this. This is the way it should be.

5) your controller is self documenting and configures using a WEB BROWSER.
  The user un-boxes your controller plugs in the AC power and Ethernet then
points the borrowers of his PC, Mac or iPhone to the controller and see a
welcome page.Many WiFi routers work like this.   The use some kind of
"zero-conf" protocol like UPnP multicast DNs or  All the documents are
stored in the web server that runs on the controller.

6) Giving an end use a text edit and access o the file system is a
technical service disaster.  User can't edit file inside their cable box
but the cable box almost certainly runs Linux.  It does fine hiding that
there is Linux inside.

7) how does user get his g-code to the machine?   Easy:  How does user
print a PDF file?  There is no complex file download or moving SD cards or
networks.  He just clicks "print".   Same here.  Possible the use drags and
drops a code file on the mill icon.   Don't let him have access to the file
system, FTP or NFS.

8) include built-in screen sharing and SSH so they your technical support
people can debug user issues without an expensive RMA process.   Use
extensive built-in diagnostics, lots on instrumentation on the hardware.

9) one more feature request.  web cam.  I want to be able to look at the
machine(s) and see them cut metal from the back seat of a self-driving Uber
car.

Lastly what is the market?  Can you sell enough of these?  It is hard for
me to see how you could pay the rent even if you sold 100 units a month.
Hopefully you work of the business case ahead of time.

On Fri, Dec 15, 2017 at 4:21 PM, Alexander Rössler <
alexander@roessler.systems> wrote:

> Hi Chris,
>
> Thank you for your input.
>
> I'm aware of Tormach, they are doing pretty good stuff and I know their
> system very well. And no, I don't want to go into the direction of
> becoming a mill manufacturer.
>
> So your suggestion two is what I'm currently researching. In my opinion
> either a low-end x86 or a high-end aarch64 CPU should do the trick. On
> the other hand some customers may prefer Windows to run their CAD/CAM
> software, so running the control software on a low-end ARM + FPGA and
> the UI on the Windows machine might be an option.
>
> But what I'm really aiming for here is all in one OEM solution. From
> what I have seen, there are pretty good alternative systems in the
> market, however, complete control systems start at 1000$ minimum, more
> realistically 10.000$.
>
> I have several customers that sell machines way below this price range
> and for them these solutions is just too expensive. So what I would offer
> is a scal-able solution, including a cheap ARM based controller with a
> basic GUI for the low-end machines and a fully supported fancy GUI 10k+$
> system the high-end machines.
>
> I'm not sure if this makes, but that's what I'm trying to figure out
> now.
>
> Cheers,
> Alex
>
> Chris Albertson writes:
>
> > If it is going to be "turn key" you are going to have to include the mill
> > or printer.  and design a far better un=ser interface.   Then if you 

[Machinekit] real time CNC using Python on Pi3

[Chris Albertson]

I just found this other project.  It is a g-code interpreter that runs on
RPi3 boards and other ARMs like that.

What is interesting is that it is written in 100% python and they get very
good real time step generation using the standard non-real time kernel.
Yes python step generation and standard Linux

How?

The method is so simple I'm mad at myself for not thinking of it.  They use
an ARM DMA channel to copy bits to GPIO.If you set up bits in RAM
correctly the DMA copies them using hardware with zero software overhead,
the bits are clocked with the system crystal clock.  Nearly zero jitter.
The method is portable across any ARM A type.

DMA seem an obvious solution.   I think the idea could be adapted to MK.

This appears to be new, code put in git hub 2017
https://github.com/Nikolay-Kha/PyCNC

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Looking for examples of conversational machine interface

[Chris Albertson]

As the title says.  I'm collecting ideas and the best place to start is
with good examples of what is currently available today.

A conversational interface to a milling machine is one that does not expose
G-Code or CAD/CAM to the user.  The user "tells" the machine what he wants,
usually by selecting from a short menu.  The machine provides a preview of
what he asked for.  Possibly the user sees a mistake and makes a correction
and then finally says "Do it."

There are some serious limits to what can be done with this kind of
interface.  But also the simple kinds of operations that can be done are
common and useful.   For example surface milling a large flat area, boring
a hole of a given diameter and depth or making a pocket.

What I'm looking for is examples of this kind of user interface and
opinions, good or bad.  Anyone have links to products and experience (good
or bad) using them.

My goals to make something VERY SIMPLE to do one-off machine tasks.  This
kind of software is NOT real-time so it could run on any hardware, even a
cell phone.

Please don't say you would never us this because you write g-code.  No, you
do that only because it is the least bad option.


Sorry to cross post this.  I know some of you will see this twice

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] BBB PRU Would 3-phase 3-axis with feedback (18 channel PRU) be possible?

[Chris Albertson]

An ARM Cortex A with on-chip PRU is made only by Texas Instruments and I
don't see this gaining market share or being used in very many new
designs.  It is becoming a speciality item.  That said, I think TI will
support their customers and continue making the old chips for sometime.
But I doubt we will see PRUs in the newest and best ARM A chips.   So if
you want to continue using PRUs you will have to be content to use these TI
chips

Like me, I think many engineers are reluctant to specify a single source
part.   When the single source decides it is no longer profitable to sell
the part you are stuck.

I think the world is moving (or has moved) to using Cortex-M for this
purpose.  The "A" and "M" type ARMs have won the battle and are nearly
ubiquitous in new designs

All that said, if this is a hobby project and you only need one or two for
your own use, use what ever you like

If you ask me about future trends in motion control, what I am seeing is a
trend to move the closed control loops physically closer to the actual
motors.   Trends move glacially slow in the machine tool world it will
catch up eventually.

for example the bests stepper motors now look something like this example:
www.leadshine.com/ntegrated-easy-servo-motors
<http://www.leadshine.com/producttypes.aspx?type=products&category=easy-servo-products&producttype=integrated-easy-servo-motors>
By moving the loop al the way out to the motor they dramatically improve
performance and reduce heat and greatly improve torque.   And don't add
much cost.  The stepper acts like a servo.

Here is another product line where the same idea is applied to serves
teknic.com/products/clearpath-brushless-dc-servo-motors/
<https://www.teknic.com/products/clearpath-brushless-dc-servo-motors/?kw=servo%20controls&ad=156385283207&gclid=CjwKCAjwmqHPBRBQEiwAOvbR81mtRSzU3QcKx6HZO1EjGqsf-uK70HeMyhD1PYOSwS2HlKpr_46MTxoCcPoQAvD_BwE>

Basically the trend is, from a big picture point of view is keep the
encoder sensor data near the motor and never bring it back to the main
controller.  If I'm designing today I want to either emulate this or
accommodate it.  Places the PRU inside the ARM chip forces the centralized
design



On Wed, Oct 18, 2017 at 10:38 PM, Bas de Bruijn  wrote:

>
>
> > On 17 Oct 2017, at 23:57, Chris Albertson 
> wrote:
> >
> > My opinion of PRUs is that I just don't want to invest in writing PRU
> code because that chip is likely is disappear soon.  When the platform
> vanishes the code will need complete re-write.
>
> Hi Chris, how come you think that the chip:platform wil vanish soon?
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] BBB PRU Would 3-phase 3-axis with feedback (18 channel PRU) be possible?

[Chris Albertson]

My opinion of PRUs is that I just don't want to invest in writing PRU code
because that chip is likely is disappear soon.  When the platform vanishes
the code will need complete re-write.

I like to code to SOFTWARE APIs  Arduino is a software API, you can change
out one flavor of Arduino for another an the code still runs evan with the
new Ardunios that don't us Atlam chips and have switched to ARM.   That
said no I would never suggest Arduino for this use case.  Just using it as
an example of a software interface.

I'd pick a platform that has a long life expectancy.  There are several and
most cost less then 1/2 the price of a Beagle or Pi3.

My experience with the low end of the ARM range, that is the M0 and M4 I
can keep up with four optical encoders each one with 64 edges per
revolution and each one spinning at 10,000 RPM.   This works out to 43,000
interrupts per second.   The M4 still had time to rise four PID loops and
keep up communications with a high speed serial line and to run a couple
housekeeping tasks in the background.   This is one a M4 with a clock of
about 100 MHz.  It might handle a lot more but I was using poured geared
motors.

If you are only doing two motors then you can use the STM32 ARM's hardware
quadrature system.  These will track encoders with some arraignment of
hardware counters and can track encoders up to about 1MHz or so with zero
CPU overhead.

One of the other things you get with ARM CotexM is hardware PWM.  You can
generate pulses with zero CPU overhead as they have hardware PWM where you
only need to load registers with the frequency and duty cycle.  No need to
use software pulse generation so the PWM is very stable as it is clocked in
hardware.

Could you do hardware three phase?  Yes.  Mostly in hardware.  The low
level pulse generation is in hardware but setting it up is complex and
you'd ned to read their reference design document.

The ARM M is quite a bit more powerful them a PRU but what makes it better
is that the ARM CPU core is surrounded by quite a lot of general purpose
hardware counters and timers and D/A and A/D so you can offload work to
external hardware

Also there is a good RTOS for ARM M.  So multitasking is easy and you need
not write to the level of the bare hardware - your code is portable with
just a recompile to a different chip. (well mostly portable)

The platform is like to stay around a while.  ARM-M is the dominat player
now and we are still in the exponential growth phase

All that said.  I think the way the motional control world is headed to
smart motors with integrated controllers and you set up some parameters to
control maximum acceleration and speed and so on and then you command them
over a serial link.   So you run data and power to each motor.   If I were
designing now from scratch. I'd emulate this and place one M0 processor
near each motor.   This would scale well too as each motor brings with it
local processing power.


On Tue, Oct 17, 2017 at 1:14 PM, Pauluzs  wrote:

> Hi all,
>
> Currently i'm looking into driving 3 phase (steppers) motors on 3 axis
> with encoders the Beaglebone.
> This because i got several 3 phase pm bldc motors, some small 48v ac
> servo's and 2 large 220v ac servo's i would like to drive.
> While looking into the 3 phase bldc steppers the idea came it would
> potentially also being able to support ac servo's.
>
> After making a pinmux layout it would be possible to connect:
>3 encoders eqep A/B/INDEX (or 3 hall sensors on the same inputs)
>6 PRU 0 signals U/V/W phase hi and low
>  12 PRU 1 signals U/V/W phase hi and low
>
> This would mean each phase could have a hi and low pru capable pin driving
> it.
> Using discrete power components it would be cheap and simple to build a
> drive.
> Or power driver IC such as the International Rectifier [IRAMS]
> <https://ec.irf.com/v6/en/US/adirect/ir?cmd=eneNavigation&N=0+4294841618> 
> (according
> to http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BLDC)
>
> There are some questions i run into:
>  Can the beaglebone/machinekit even keep up with this amount of pwm pins?
>  Should i use the pru stepgen code? (stepgen does not seem to support 3
> phase)
>  Should i use the pru pwm code?
>  Use the bldc component with standard writes?
>  Or use the bldc component with pru_pwm?
>
> Usefull thoughts or comments are most welcome,
>
> Thanks,
>
> Paul
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
>

Re: [Machinekit] intergrate computed torque control (PD controller)

[Chris Albertson]

OK,  you have an AC servo motor.What are the electronics that sit
between the motor and the computer?   What motor driver are you using?
 Software actually never "sees" the motor only the driver electronics.

Then the next question:  Is encoder data run to the computer?  I assume it
is and you wish to close the loop in software.  However there are servo
drivers that close the control loop themselves and then the servo motor
looks like a stepper motor to your software.I assume you are not doing
this and encoder data goes to the computer.  Is it quadrature with index or
something different?

So what does the electronic interface look like.  Software in LinuxCNC sees
only this interface

There are many ways to interface a servo.  In the worst case you might be
sending PWM to a mosfet h-bridge switch that directly controls current to
the motor or what most people do is connect a commercial servo amplifier.
Some drivers accept "step and direction" from the computer.

No one can answer software questions without knowing how the electronics
works.



On Sun, Oct 1, 2017 at 1:49 AM, thangle  wrote:
>
> the arm robot i want to controll is like scara but it has one more dof
> (5dof) however it just control 4 axis xyzC (already solved kinematics and
> dynamics equation). in order to control it, i will use AC servo (or DC
> servo). I think it's possible to use Gcode for planning trajectory.About
> ROS, i 'm having plan to use it in future with another robot but for now, i
> still want to try control arm robot by linuxcnc
>

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] intergrate computed torque control (PD controller)

[Chris Albertson]

Is LinuxCNC/machinekit  the right tool for this?   It's advantage is that
it has a fast servo loop but there are many things in does not do and
linuxcnc is basically a g-code interpreter and unless the robot arm is just
doing blind repetitive work g-code is not going to work.  For example I
don't see how to integrate g-code with a vision system.

Why step back and describe the big picture?  What is the goal?   And what
kind of motors do you have.  Are these servo motors with encoders?  You are
asking very low level detailed questions but with no context.

See the link below.  This is what I'm using to control an arm.  The article
is very high level and assumes a lot about the reader.  But in general arm
control is not easy so you REALLY want to make use of existing software.
This describes how to use some existing software for "constraint controlled
inverse kinematics" of 6+ DOF arms.  It can compute all the motion planning
and accelerations and torques to (say) reach around an obstacle and place
the end effector at the desired location and orientation all in realtime.

I would strongly suggest getting this all to work on standard PC hardware.
One that has good performance and loads of RAM.   Then if needed move the
solution to a smaller platform like RPi3.Starting on the small platform
is not nearly as easy.

ros.org/arm_navigation/Tutorials/Running arm navigation...
<http://wiki.ros.org/arm_navigation/Tutorials/Running%20arm%20navigation%20on%20non-PR2%20arm>




On Sat, Sep 30, 2017 at 9:29 AM, thangle  wrote:

> Hi,
>
> i having a project about control arm robot, and i'm research dynamic
> control ( computed torque control PD). If any projects used to do it in
> linuxcnc(machinekit? One thing i can do is write a C code to calculate
> Torque of joints. I dont know how to intergrate them into linuxcnc. It's
> great if there are some examples for reference because i'm still quite new
> in linuxcnc(machinekit) and embedded.
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Steprate Question

[Chris Albertson]

This sounds like a job for an FPGA.  1MHz loops are hard to do in software.
   Even with custom PRU code, if it worked yours have job for life
maintaining it as new versions of the CNC software, OS and toolchain come
out over the coming years and decades.

Mesa cards are not that expensive and other FPGA cards can be 1/2 their
price.   So, just move the 1MHz loop into hardware.

One problem with software is that when you look at  results at the
sub-microsecond level differences is the dynamic code path lengths matter.
  For example does it ALWAYS requires 15 clock cycles to turn on a bit?
No, likely there is an "if" statement some place where one branch is
longer.At low speeds this is a 0.01% effect at higher speeds this might
be a 10% effect.   You don't know the magnitude of the problem until after
you write the code and see if you were able to make every execution path
the same length.   Likely not so you have jitter at the XX% level.

This is where FPGAs work best because you can clock the output pluses
relative to a divided down crystal oscillator

On Mon, Jun 12, 2017 at 7:03 AM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 6/10/2017 1:06 PM, Sag ich Dir nich wrote:
> > Hello,
> >
> > if i want to drive 5 axis with each 1 MHZ steprate, do i need to reach 5
> MHZ
> > Stepgen or 1 MHZ?
>
> You need to a 2 MHz base thread (or 500 nS PRU period) which will give
> you a 1 MHz maximum step rate (1 thread period high, one thread period
> low).
>
> This is very easy to do if you're using hardware, but not so easy in
> software.  I doubt an x86 can run interrupts anywhere close to that
> fast, and an ARM certainly can't.
>
> The PRU on a BBB can probably be coerced into running this fast, but
> you'll need to optimize the code.  The existing hal_pru_generic was
> written for flexibility more than absolute speed, and probably won't
> go faster than several hundred KHz step rates with 5 stepgens.  To get
> into MHz step rates, you'll probably need to hard-code the PRU logic
> (instead of building a chain of "tasklets" as is done now) and keep
> all of the state information in registers.  It should be fairly simple
> to do, but you still might not quite make it to a 1 MHz step rate (the
> 500 uS task period only gives you 100 instructions to do step/dir
> generation for 5 channels, or 20 instructions per channel.  The
> step/dir code isn't super complex, but is more than 20 instructions
> through the worst-case path, and some of the instructions take more
> than 1 clock (5 nS).  Getting rid of the memory accesses (required for
> the current "tasklet" structure) and putting everything in registers
> ought to get you close to the required speed.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Cheapest way to get +/-10V signal from x86 computer with encoder input

[Chris Albertson]

He is talking about a +/- 10 volt SIGNAL not a +/- 10 volt power supply.
  His servo amp converts this analog signal to velocity.  The signal works
so if it is 0V the motor stops, +5V  it runs forward at 1/2 speed and -5V
is backwards at 1/2 speed and so on.

The suggested I offered was to use a bridge made with four cheap transistor
and it would need 12 volt power.  So there is a use for the ATX power
supply outputs

On Mon, Mar 20, 2017 at 10:56 AM, Daren Schwenke 
wrote:

> You have +12v/-12v available from the ATX supply already, albeit the -12v
> is limited to about 0.5 amps.
> The simple, in your scrap box already solution would be wire a couple
> diodes in series and add two filter caps.
> 0.6v-1.2v drop per diode, add them till you are at your 10v.
>
> 0On Sunday, March 19, 2017 at 12:09:42 PM UTC-4, Pruska Modr wrote:
>>
>> Hi,
>> is there any way how to connect to computer of the x86 platform to servo
>> amplifiers which require +/-10V for velocity loop and to encoders working
>> on the 5V logic and do the PID position control loop inside Machinekit
>> besides the MESA FPGA+7i77 cards? It would be only temporary solution until
>> I figure out something better so I would like if it was cheap.
>>
>> Thank you.
>> PM
>>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Re: Getting started with Servoes

[Chris Albertson]

Step/Direction controllers close the servo loop inside the controller.
I wonder if it is better to do that inside the EMC2/MK HAL file?

The specific step/direction controller linked to below is a closed
source project.   I hate to build things when I can't see how they
work.


On Wed, Mar 15, 2017 at 10:17 AM, Claudio Lorini  wrote:
> ...well, if you're willing to do some electronic DIY, there are some
> interesting servo dc driver projects around:
>
> http://www.uhu-servo.de/
> https://sites.google.com/site/marcosinatti/elettronica/downloads (sorry, in
> Italian)
>
-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] Getting started with Servoes

[Chris Albertson]

Hi,

I happened upon a few servo motors and thanks to people on this list I
know how to measure their performance in a simple but good enough way.
  They are DC brushed motors with TTL compatible optical encoders that
send quadrature and index pulses.   They are about right for use on a
small to medium machine tool.

So far I've run them off a bench power supply and looked at the
encoder output on a scope and frequency counter.

Question is how are people connecting these to Machine Kit.   I'm
inclined to use a simple dual H-Bridge using four MOSFETS.EMC2/MK
would send PWM and direction and read the quadrature A and B channels.
  I don't see a use for Index as I'd be controlling X, Y, Z on a small
mill.

Are there other or better ways to connect the motor?   I notice Gecko
makes a controller that accepts step and direction inputs and makes
the servo look like a stepper.   This has the advantage that it turns
it into something I've used before

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] How to figure out specs of a surplus servo motor?

[Chris Albertson]

Hopefully you all can see this.  I posted the images to Flickr.   This
should link to them https://www.flickr.com/photos/chris_albertson/shares/
h7h52y

There are two different types of motor.

1) Made by Electro-Craft.  The label reads "Model E540" and it might be 3
to 4 pounds  It has a BEI encoder on it and I have the specs for the
encoder.  It has 250 steps per revolution plus an index pulse.

2) Made by Tamagawa, or at least the encoder is made by them.  There is no
cable on the motor itself, only the encoder.  This one weighs about one
pound.

Yes I can apply a known torque, a lever arm and a weight then see how much
current it takes to just make it move.But it would be good to have some
kind of starting guesses for each motor.  How many amps are typically safe?

I hope to use the larger motor for the Z axis of a Harbor Freight mini
mill.  One of the smaller motors I hope will power (via about 100:1
reduction) the first joint of a 6 DOF robot arm.  This would be just a
basic horizontal turn table that carries the rest of the arm.

One more question.  Notice in the photo of the Tamagawa motor, the one with
the laminated hexagonal case, that there are FOUR power terminals at 90
degree intervals around the motor case.   Two of these, 180 degrees apart
as connected.   Why would there be four?


Thanks,

Chris

On Mon, Mar 6, 2017 at 3:02 AM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 3/5/2017 8:22 PM, Chris Albertson wrote:
> >
> > Pulling the cover off an encoder I see three channels (rings) of slots
> > on a thin stainless disk.  One looks like it is for quadrature
> > encoding and has over 1000 slots, one is an index and then there are
> > some S-shape over lapsing holes.I know how to figure out encoders:
> > Guess that two leads are power and look at the signals on the outers.
> > But motor voltage, max current and torques?   How to figure those out?
>
> Are they brushed DC motors, or 3-phase AC?
>
> If they are 2-wire DC motors, you can figure out the motor voltage by
> applying a known voltage to the motor and measuring it's speed.
>
> Current = torque, so maximum torque will be limited by how much
> current you dump into the motor, which will mostly be limited by heat.
>  Again you can figure out the motor's torque constant by applying a
> known current and measuring the torque (or apply a known torque and
> measure the current required to get the motor to move).
>
> You won't know the motors designed limits, but with a voltage and
> current constant you can figure something reasonable and/or compare
> with currently available motors of similar size.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Machinekit] How to figure out specs of a surplus servo motor?

[Chris Albertson]

So I have decided to at least experiment with a servo motor.  I know
almost nothing about them.  But I just got hold of four of them.  By
the date codes these were made in the late 1990's and pulled off
working equipment.   I've tried to Google the part numbers and looked
at manufacturer's web sites but these are nearly 20 years old and no
longer made and not in the archived manufacturer catalogs.  One looks
about NEMA34 size and 4.5" long, three others are about 2/3 that size
and 1/2 the weight

Pulling the cover off an encoder I see three channels (rings) of slots
on a thin stainless disk.  One looks like it is for quadrature
encoding and has over 1000 slots, one is an index and then there are
some S-shape over lapsing holes.I know how to figure out encoders:
Guess that two leads are power and look at the signals on the outers.
But motor voltage, max current and torques?   How to figure those out?

-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

Re: [Machinekit] Machinekit image server is unresponsive

[Chris Albertson]

As a test I just downloaded the image you linked to.  Took all of
about 40 seconds for 758.5 MB

Maybe it was broken 60 seconds ago but it worked once for me. at about
10:35a Pacific Time.

On Sun, Mar 5, 2017 at 10:30 AM, Philip Hiatt  wrote:
> Hello everyone,
>
>My name is Philip Hiatt; for most of the morning I have been trying to
> download a pre-built image of Machinekit.
>
> I am not a newb when it comes to Linux, the URL I am trying to get is;
>
> https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/lxqt-4gb/bone-debian-8.7-lxqt-4gb-armhf-2017-02-12-4gb.img.xz
>
>
> I have let wget sit for as long as an hour, wget says connected but there is
> no response for the sever. I have also tried other URL's with no luck.
> Also, when using http to get the image, I get a timeout error.
>
> Are these URL's correct?? Is the server down??
>
> Thanks
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to machinekit+unsubscr...@googlegroups.com.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.



-- 

Chris Albertson
Redondo Beach, California

-- 
website: http://www.machinekit.io blog: http://blog.machinekit.io github: 
https://github.com/machinekit
--- 
You received this message because you are subscribed to the Google Groups 
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.