OpenPnP and LinuxCNC > yes/no?

[jbasia]

My old PnP (with proprietary software) is running on Windows 7. A new controller is in the planning (already ordered). Obviously Windows 7 is out.

Hardware:

AMD Athlon 7850/4Gb RAM (probably from 2009)

That PC has a partition with an older LinuxCNC (from ~2018 I guess)

Is that PC even suitable for OpenPnP? Can OpenPnP run on LinuxCNC? (My mill is connected via parallel port - mill and PnP will not run at the same time)

It's my understanding that LinuxCNC is an O/S and does 'things' to Linux that may (or may not) effect OpenPnP.

Alternative would be to have OpenPnP on a different partition with its own O/S (also no problem) - what O/S would be suitable (considering the age of the hardware)?

If that hardware is totally unsuitable I still have a modern i5 Win10 Notebook

[Mark]

> Is that PC even suitable for OpenPnP?

Hardly. It will probably work, but slow. The RAM is also tight. There are some recent additions in computer vision that require quite some CPU oomph.

> Can OpenPnP run on LinuxCNC?

I frankly don't know. User FlashPackets started down that road, but never reported back in the end.

https://github.com/openpnp/openpnp/issues/1341

The way I understand it, LinuxCNC was a nice solution back when MCUs where weak and/or proprietary, and the whole Arduino/DIY electronics culture was not yet born. There were no affordable Open Source controllers, so a makers's PC was the natural "escape route", at first abusing the parallel port as GPIO, something like "real-time computing" was still possible on DOS/early Windows, later on special RT Linux. Nowadays, I don't see how this makes sense anymore. The needed interface cards are much more expensive than any good controller, and most of these are proprietary commercial products, unlike the Open Source controllers and firmwares we recommend.

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares

Full disclosure: LinuxCNC has one nice features, that I'm yet missing on Open Source controllers, that is motion blending:

https://youtu.be/csFE-4XwaYE

https://groups.google.com/g/openpnp/c/JfxgCxR2rGc/m/IcGMDmldDwAJ

I tried to add it to OpenPnP, using interpolation on conventional controllers, but the needed fine-grained path is too much data to transmit in reasonable time (it works for small moves, but for the practical larger moves, you lose more time sending path sequences, than what you gain cutting corners in motion):

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending

I'm still waiting for the first Open Source controller to implement it (G64, G61 commands). 😎

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7a2bc85b-f79c-4a88-a405-7fff3ae918efn%40googlegroups.com.

[bert shivaan]

Mark I would like to kindly disagree with the idea that the current controllers make LinuxCNC unnecessary.

The problem with all of the controllers I have delt with including Duet is they lack the real time response needed for running a machine in a real way. What I mean is if you want to run a mill for example like a 3d printer they are fine. But after 30+ years of both manual machining and CNC machining it just does not work. For instance when I hit the pause button, the machine need to stop right then and there. Not when it gets to the end of whatever it is thinking about. I do not believe ANY controller supports rigid tapping. I am not aware of any controller that will support tool changing. And for less than $100, I can add an interface card from Pico or Mesa that will turn my old computer into a fine machine controller. Up to 9 axis!!

I agree LinuxCNC is not the option for 3d printing. I am dabbling with the idea to use a 3d printing solution for a CO2 laser. Like a Duet card or the like. LinuxCNC is not needed for openPNP although I DO think openPNP could be like on steroids if it had the option to work like LinuxCNC. Even the Klipper users use what I call the LinuxCNC approach. The program is crunched on the RPi, then data is fed to the controller to tell it what pins to turn on and off. The controller is not controlling at that point, it is just an interface card between RPi and the machine.

Do not get me wrong, I love all the methods available to us for controlling machines these days, but in no way has LinuxCNC been made obsolete by the embedded controllers IMHO.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c86c6c35-a9cf-6731-a64b-1388e69c364f%40makr.zone.

[Jarosław Karwik]

I would say there is always middle ground - like in Klipper case you mentioned.

My industrial controllers are placed in machines like these -> https://felix-gluer.com/

They operate in mixed mode - for the most of the time the trajectory is precomputed on PC  and loaded into the controller ( it has large external flash) and operates independently. The PC software just watches feeedback from the machine.

In some moments the PC talks to plc controllers, pumps, moves the gantry to clean the nozzless  - as direct immediate commands.

It is capable of stopping the moves immediately ( controller handles it) - in reality I have added breaking curve to avoid stressing mechanics. It can continue program from such stop without loosing anything ( slowly accelerating again up to previous speed).

Morever - even ESTOP - which is handled both in my controller as well as directly in servos is notthe  end of the world - due to encoders in motors it does not even need homing ( PC is able to restore gantry to known position).

Most of the controllers are capable of such operation - even if it is not implemented there.

[bert shivaan]

I agree with Jarslow, there is absolutely a middle ground. It really is about using a flat head screwdriver or a hammer. I WOULD NOT want to use LinuxCNC to run my 3d printers, and I will not use the somewhat autonomous 3d printer controllers to run my mills.

And to be sure, MCU's have been able to control machines for many years before the boom of controllers hit. After all we sent the first space shuttle up to space with the computing power of a digital watch. CNC machines have been around since LONG before 32 or 64 bit computing doing things like high speed machining with look ahead in the control.  I had a CNC machine about 25 years ago that the biggest chip on it was a shift register. And it ran gcode. It also responded in realtime, and it could hold and resume from the control. And of course all the machines I am talking about weigh more than 7000 pounds.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3c75634d-d67f-4929-a63c-fa940aadb88dn%40googlegroups.com.

[Mark]

Hi Bert,

thanks for sharing your experience. Such missing insight on my side is why I carefully wrote "The way I understand it..." 😁 But I should probably have made it clearer, that I was mostly just speaking with a Pick and Place application in mind.

One specialty of PnP is its interactivity. It does not just blindly execute a lengthy G-code file, that was generated in full beforehand (CAM post-processor/slicer etc.). Instead it interacts with computer vision, vacuum sensing etc. to control the motion spontaneously. For almost all the other applications (milling, laser cutting, 3D-printing) this is not the case. Pick and place spontaneous interaction has to be fast, per round-trip, therefore the time it takes to bake G-code into whatever "executable form" is needed, and then transmitted to the actual real-time hardware (Mesa interface card, Klipper firmware, or whatever), is relevant. I know this ping-pong time can be substantial for Klipper (although less than I thought). I don't know about LinuxCNC.

> For instance when I hit the pause button, the machine need to stop right then and there.

I think TinyG has that. And it still observes acceleration/jerk limits while breaking, holding positional accuracy.

> for less than $100, I can add an interface card from Pico or Mesa that will turn my old computer into a fine machine controller. Up to 9 axis!!

For real? When I looked into that, about four-five years ago, this was a completely different picture. It started with the fact that you actually needed three layers of hardware: one to execute the motion in real-time/generate the IO, one for IO-protection/physical wiring, and one for actually driving motors (power electronics). And each was quite expensive (and closed source). I now tried to find fresh information online, but I haven't found anything sounding like "less than 100$", let alone for 9 axes! Please send some links 😎

In contrast, with a Duet 3D for instance you have everything you need in one board, just connect your motor wires.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxDCLayb9XTNdOBTsF2Z7d5aJYinrDNo6j%2BfyRfERfN5g%40mail.gmail.com.

[jbasia]

Thanks. I sort of forgot about the vision that probably requires some good computing power. I will probably look into better PC too. Still like to use Linux, but will keep LinuxCNC separate. The two will never run together anyway.

For the very very basic first setup I will try the existing PC.

The Chinese PnP runs with that Windows 7 PC. Also with vision (can't do SOT-23 though), generally "okay".

Can't await to get my parts (probably stuck in Covid lockdown now).

PS: That LinuxCNC video is impressive. The whole canal is interesting. I stick with OpenPnP though.

[bert shivaan]

You are fully correct, I forgot about the motor drivers.

And after thinking about likely most controllers will allow pause and resume if buttons are wired directly to them. But they still won't tool change to my knowledge.

I also have been toying with the idea of trying to use openPNP as a mill controller. I am not convinced it can't be done. The value is the vision. That would be SO SO SO awesome to have in a machining controller.

LinuxCNC has 2 possible threads running. 1 is servo, the other I forget the name of. One of them typically runs every millisecond. This is used for servos that track their movement and only need positional information every .001 seconds. of course this is given to all axes in the same thread to keep motion coordinated. The other loop is for running typical parallel port I/O to steppers. this loop typically runs every 50 micro seconds or so. Gives the step and direction pulses direct to the stepper driver. So from an information speed viewpoint, if you had packets of step information every 50uS or better, it would be plenty fast enough maybe. But I digress from the original topic.

but I think you can still get a MESA 5i25 for under $100. This is needed if you want more than 4 motor controls since the parallel port is limited in pins. That was what I was thinking about . But to be sure, I can get step stick style from drivers from china for pretty dang cheap so maybe less than $200 for nine steppers drivers and a MESA 5i25? i still need motors of course.

Having said all that, I still would not use LinuxCNC for my pic and place machine. openPNP is far far superior for that task. hammer to drive a nail, screwdriver for screws. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2f11f968-d388-5bd9-29bb-9977fefcd63c%40makr.zone.

[Mark]

> I still would not use LinuxCNC for my pic and place machine. openPNP is far far superior for that task. hammer to drive a nail, screwdriver for screws. :)

Now you are comparing "hammers with screws" 😁

OpenPnP is not an alternative, it only generates the G-code, that is then interpreted by "something else". This "something else" could be a controller like Duet, Smoothie or Klipper or LinuxCNC if there is a way to send G-code over a socket interactively.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNx5x%2Bijz1Fs9OVYqNGAQQW3HC2F83LfjE17jWzehkVkYA%40mail.gmail.com.

[Markus Rechberger]

it can be used and will be okay, linuxcnc is only a motion driver.

I think linuxcnc would be a little bit too powerful for this
application - since the pick and place software itself has the main
priority and not directly synchronized motion between X/Y/Z etc.
OpenPNP would just forward the G-code to linuxcnc and linuxcnc would
control motors eg. via step/dir controls (there are also a few other
ways)

As far as I know linuxcnc only supports trapezoidal acceleration /
de-acceleration at the moment, there are a few trees on github which
support s-curve acceleration (but don't seem to work properly for CNC
yet) they certainly will work for pick and place acceleration where
the movement doesn't have to be synchronized. The entire movement
would be smoother with an s-curve setup (jerk limiting system).

For a pick and place system I'd rather go with a small microcontroller
for the motion system rather than a PC with the flexibility of
LinuxCNC.
I'm using LinuxCNC for my CNC Mill and Lathe for 1 1/2 years and
wouldn't use something different anymore - but for a pick and place
system as mentioned I wouldn't use it.

So if you want to give it a try it will certainly work but cost a
little bit more than a small microcontroller board.


Markus

[Markus Rechberger]

On Thu, Dec 1, 2022 at 4:58 PM Mark <ma...@makr.zone> wrote:
>
> > Is that PC even suitable for OpenPnP?
>
> Hardly. It will probably work, but slow. The RAM is also tight. There are some recent additions in computer vision that require quite some CPU oomph.
>
> > Can OpenPnP run on LinuxCNC?
>
> I frankly don't know. User FlashPackets started down that road, but never reported back in the end.
>

axis is written in Python, you can just check how to submit G-Code via
MDI to linuxcnc or even open a tcp socket which can take MDI commands
via Axis and poll or give feedback if the command is executed. There
are many ways to submit g-code to linuxcnc.
I never directly submitted g-code via terminal, but I have modified
axis. I'm sure there are some commandline commands which can do that
as well.

> https://github.com/openpnp/openpnp/issues/1341
>
> The way I understand it, LinuxCNC was a nice solution back when MCUs where weak and/or proprietary, and the whole Arduino/DIY electronics culture was not yet born. There were no affordable Open Source controllers, so a makers's PC was the natural "escape route", at first abusing the parallel port as GPIO, something like "real-time computing" was still possible on DOS/early Windows, later on special RT Linux. Nowadays, I don't see how this makes sense anymore. The needed interface cards are much more expensive than any good controller, and most of these are proprietary commercial products, unlike the Open Source controllers and firmwares we recommend.
>

Tormach is using LinuxCNC under the hood for their commercial CNC
machines, well and my machine runs with LinuxCNC too, soon with 5
micrometer linear glass scales.
LinuxCNC is a nice solution and far from outdated.

> https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares
>
> Full disclosure: LinuxCNC has one nice features, that I'm yet missing on Open Source controllers, that is motion blending:
>
> https://youtu.be/csFE-4XwaYE
>
> https://groups.google.com/g/openpnp/c/JfxgCxR2rGc/m/IcGMDmldDwAJ
>
> I tried to add it to OpenPnP, using interpolation on conventional controllers, but the needed fine-grained path is too much data to transmit in reasonable time (it works for small moves, but for the practical larger moves, you lose more time sending path sequences, than what you gain cutting corners in motion):
>
> https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending
>
> I'm still waiting for the first Open Source controller to implement it (G64, G61 commands). 😎
>

hmm? G61/G64 is available in linuxcnc.
https://linuxcnc.org/docs/2.6/html/gcode/gcode.html#sec:G64


Markus

> _Mark
>
> On 01.12.2022 05:48, jbasia wrote:
>
> My old PnP (with proprietary software) is running on Windows 7. A new controller is in the planning (already ordered). Obviously Windows 7 is out.
>
> Hardware:
> AMD Athlon 7850/4Gb RAM (probably from 2009)
>
> That PC has a partition with an older LinuxCNC (from ~2018 I guess)
>
> Is that PC even suitable for OpenPnP? Can OpenPnP run on LinuxCNC? (My mill is connected via parallel port - mill and PnP will not run at the same time)
>
> It's my understanding that LinuxCNC is an O/S and does 'things' to Linux that may (or may not) effect OpenPnP.
>
> Alternative would be to have OpenPnP on a different partition with its own O/S (also no problem) - what O/S would be suitable (considering the age of the hardware)?
>
> If that hardware is totally unsuitable I still have a modern i5 Win10 Notebook
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7a2bc85b-f79c-4a88-a405-7fff3ae918efn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c86c6c35-a9cf-6731-a64b-1388e69c364f%40makr.zone.

[Mark]

Hi Markus,

just so you know, your messages have only just now arrived in my inbox. For some strange reason google groups sometimes does that.

I guess your valid arguments are already mostly conceded by me in response to Bert.

> hmm? G61/G64 is available in linuxcnc.

If you read carefully, that's exactly what I wrote, and what is a point where LinxCNC could in deed shine! Also impressively demonstrated in the linked video.

https://youtu.be/csFE-4XwaYE

So if anybody can make LinuxCNC work nicely with OpenPnP, I would be very glad. 😁

You mentioned some possible solution using a socket, but nobody really confirmed that so far. This must include the necessary response behavior (M115, M114 etc.). One thing that also must work, is blocking behavior in case of M400, i.e. the "ok" response must be delayed in some way until the machine has finished moving.

_Mark

[Jason von Nieda]

Hey Mark,

New posters, or posters using a new email address, need to be manually approved before their messages are sent to the list. This is a moderation setting on the list that I use to ensure we don't get SPAM and NSFW material. I woke up about an hour ago and approved those messages :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/01da8f89-97b1-2407-1095-7cc2404edc74%40makr.zone.

[Mark]

OK, that explains this case. But a delay also sometimes happens with already approved members, including myself. 😉

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1fdb493a-7865-4982-a744-d0d0cd48c770%40app.fastmail.com.

[dc42]

>> The problem with all of the controllers I have delt with including Duet is they lack the real time response needed for running a machine in a real way. What I mean is if you want to run a mill for example like a 3d printer they are fine. But after 30+ years of both manual machining and CNC machining it just does not work. For instance when I hit the pause button, the machine need to stop right then and there.  Not when it gets to the end of whatever it is thinking about. 

This feature is planned for RepRapFirmware 3.5. Meanwhile you can achieve a good approximation of it in CNC applications by enabling motion segmentation using the M669 command.

 >> I am not aware of any controller that will support tool changing.

E3D, Jubilee and other tool changing systems run on Duet + RepRapFirmware.

>> And for less than $100, I can add an interface card from Pico or Mesa that will turn my old computer into a fine machine controller. Up to 9 axis!!

The Duet 3 ecosystem + RepRapFirmware supports up to 15 axes + 10 extruders. The boards do cost more than $100, but of course this includes the stepper drivers - does your $100 board?

>>  Even the Klipper users use what I call the LinuxCNC approach. The program is crunched on the RPi, then data is fed to the controller to tell it what pins to turn on and off. The controller is not controlling at that point, it is just an interface card between RPi and the machine.

Running a real-time application under a non-real-time OS always worries me, because then you are relying on there being enough CPU power to meet the real-time requirements at the same time as servicing everything else running on the machine. Obviously it can be made to work if you are running a small system and you are careful about what else you run on it under that OS; but Duet customers include demanding industrial users who need guarantees. I'd be much happier with that approach if it used e.g. a 4 core CPU where 3 cores ran Linux and the 4th ran the real-time code independently of Linux.

[bert shivaan]

Hi dc42,

E3D, Jubilee and other tool changing systems run on Duet + RepRapFirmware.

I prolly need to be more versed on this I suppose. So if I send an M6 Txx they will go and fetch that tool with new length compassion (set when the tool was set) and be ready to roll? Can I have 22 tools like my VMC's do?  or 100 tools like my hortozintal? I am not trying to be contrary sounding, I am just in the dark so I ask

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f341549c-2b04-4c40-b4a8-406efdc0aff9n%40googlegroups.com.

[dc42]

Hi @cncmachineguy,

Basically yes, if you write suitable macros for tool pickup and release. However, RRF normally executes tool changes as soon as the T command is executed. It does not support the M6 command, although you can define it yourself by putting a macro file called M6.g containing the appropriate commands on the SD card. The actual behaviour of tool changes when you use the T command is determined by other macro files, so you could change those to defer the actual tool change until M6 is executed if you want to.

RRF holds XYZ offsets for each tool, so differences in tool height can be handled automatically. You can also probe with the tool against a switch to set the tool offset automatically.

There are some CNC features that RRF does not yet support, such a cutter radius compensation. We are gradually improving the number of CNC-specific commands we support, for example we are introducing inverse time mode in RRF 3.5.

If you want to learn more, you may wish to post your questions in the CNC category of the Duet3D forum at https://forum.duet3d.com/ where users who understand CNC better than I do will be better able to discuss with you the advantages and limitations of RepRapFirmware for controlling CNC machines.

[Jon Elson]

I am a (minor) developer on LinuxCNC, and have used two P&P machines in my shop.  The first one had fairly decent error recovery, the 2nd machine has VERY sophisticated error recovery.

I really don't see how LinuxCNC would handle pickup errors and other issues mid-job.  And, having used two different high-end P&P machines, I can guarantee errors are going to be common.  Cover tapes don't peel, parts fall out of tapes, and on and on.  My old P&P had no vision, so that was simple, the new one has flying vision, so there are all sorts of vision alignment errors that can also occur.  My current machine uses the vision system to detect differences in nozzle length after a tool change.

Jon

[bert shivaan]

Thanks Jon,

My apologies to the OP. The original question was about what computer to buy to run openPNP. I think I lead this astray responding to Mark mistakenly thinking he was feeling like linxCNC was dated.

Any way I want to not mislead this topic any further.

I think Mark may have answered the OP, but if not please clarify if you still need help?

I promise not to take it off topic :)

Bert

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dfeb89b0-ae08-4979-8aba-f3e45e34a76cn%40googlegroups.com.

[Markus Rechberger]

On Sat, Dec 3, 2022 at 7:45 AM Jon Elson <el...@pico-systems.com> wrote:
>
>
> I am a (minor) developer on LinuxCNC, and have used two P&P machines in my shop. The first one had fairly decent error recovery, the 2nd machine has VERY sophisticated error recovery.
> I really don't see how LinuxCNC would handle pickup errors and other issues mid-job. And, having used two different high-end P&P machines, I can guarantee errors are going to be common. Cover tapes don't peel, parts fall out of tapes, and on and on. My old P&P had no vision, so that was simple, the new one has flying vision, so there are all sorts of vision alignment errors that can also occur. My current machine uses the vision system to detect differences in nozzle length after a tool change.

LinuxCnC would just act as motor driver, pick up errors still have to
be handled via openpnp. Commands can be sent through a live interface
eg. mdi.
The nice part here would be that linuxcnc offers endless connectivity,
you can just wire up everything ... the cheap way via parallel port
cards, or even esp32 drivers etc.
However I also think linuxcnc is actually too powerful for this, that
flexibility is just not needed (but it's the user's choice of course).

Markus

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dfeb89b0-ae08-4979-8aba-f3e45e34a76cn%40googlegroups.com.

[Mark]

Hi Jon,

> I really don't see how LinuxCNC would handle pickup errors and other issues mid-job

Just to exclude misunderstandings if there are any (not sure). In any case, also for others perhaps following this:

LinuxCNC would not have to "handle pickup errors and other issues mid-job". That's the job of OpenPnP.

OpenPnP would use LinuxCNC like a controller. It generates G-code on the fly, it sends it to LinuxCNC (e.g. over a socket). LinuxCNC then needs to execute this G-code as fast as possible. Some commands also require it to respond back in a machine-readable manner, like report the current position, or (if it can do that) report read sensor input (vacuum sensing). Yet another command (typically M400) needs to wait until the machine has physically done all the queued commands, before it is allowed to respond (blocking). The snappier this send/execute/respond cycle is, the better-suited LinuxCNC would be for OpenPnP.

Using the motion and feedback from LinuxCNC interactively, OpenPnP can do everything that is required for Pick and Place operation. OpenPnP also uses attached cameras for computer vision. It uses positional vision to align parts i.e. offset the subsequent motion coordinates etc. It repeats a pick&place cycle when computer vision or vacuum sensing detects that the part was not picked right. And more.

So the "brains" is in OpenPnP, LinuxCNC would just be the "muscle".

OpenPnP can also use multiple drivers, cameras etc. They are all coordinated against each other by OpenPnP. Which is only possible because Pick&Place does not need hard real-time coordination between axes (unlike a mill, for instance). Using multiple drivers, you could for instance do the motion on LinuxCNC, but leave vacuum sensing, feeder actuation etc. to other (simpler) controllers.

For contrast: I know this is completely different in almost all the other CNC applications, where everything is baked into G-code and can be generated up front (and at leisure). In these scenarios, all the things that need to be responsive at run-time, examples being probing or hard tapping, must happen autonomously inside the controller, or in that case inside LinuxCNC. As I explained above, for OpenPnP, you simply need to let go of this notion.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/dfeb89b0-ae08-4979-8aba-f3e45e34a76cn%40googlegroups.com.

[Mark]

> My apologies to the OP. The original question was about what computer to buy to run openPNP.

Well the OP's choice of topic for this conversation was "OpenPnP and LinuxCNC > yes/no?".

So I do think this is still firmly on topic.

This is an Open Source community forum, so the conversation is not merely for the OP, but for anybody interested in the same question (including potentially at a later date). So even if the OP probably already has decided against using LinuxCNC (and his old computer), this might still be interesting for somebody else.

I'm also personally interested to see LinuxCNC adopted as an OpenPnP compatible controller, simply to finally have that magic G64 support with motion blending! I would absolutely love to see that first video where it races through the corners!! 😁

https://github.com/openpnp/openpnp/wiki/Motion-Planner#motion-blending

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNxu4QvD60%3Dd1K%2B%3DGP6RKjSOh4dPPx-EpcZsisiam-7cwQ%40mail.gmail.com.

[Jarosław Karwik]

I might be able to fulfill your dream about motion blending :-), but lets discuss it somwhere else : https://groups.google.com/g/openpnp/c/Zs6PBCyBI9o

[Cosyne Wave]

There is a guy who did some impressive things with LinuxCNC:

http://yurtaev.com/

Probably lurking silently here.

Obviously he knows a thing or two about movement, motor drivers, PnP and LinuxCNC, and seems a very competent developper. 

https://www.youtube.com/watch?v=hb4kSznglo0&t

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/248bceac-3e44-0af2-c114-e8c1fe6b81fd%40makr.zone.

[jbasia]

On Saturday, 3 December 2022 at 09:20:45 UTC+8 cncmachineguy wrote:

Thanks Jon,

My apologies to the OP. The original question was about what computer to buy to run openPNP.

No worries mate. My question was very basic. 

 

I think I lead this astray responding to Mark mistakenly thinking he was feeling like linxCNC was dated.

 

LinuxCNC is dated! But that is my version on my PC. But it does not matter be cause I could use it for my CNC router perfectly. I know there are newer version now, so it can only get better.

Here is my confusion, the version I have (~2018 or earlier) is not a CNC software - it's a Linux OS with inbuild CNC capabilities - so LinuxCNC was not something you could install to Ubuntu or whatever. So, since the LinuxCNC is optimized for CNC I wonder if OpenPnP will somehow clash for whatever reason?

But the question is theoretical, I rather go for dual boot and have OpenPnP on another partition - is there a preferred Linux distribution I should use?

 

[Jon Elson]

LinuxCNC has had motion blending with G64 options since at least 2005.

Jon

[Markus Rechberger]

Did you have a look at (especially at the bottom):
https://linuxcnc.org/docs/html/man/man1/linuxcncrsh.1.html

You can open a telnet session to linuxcncrsh and send some commands, I
guess implementing such a driver in openpnp should be very easy.

set mode mdi
set mdi g0x1 <-

Markus

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8c3d32cf-c2cb-40c3-8ebd-c25e361a9f90n%40googlegroups.com.

[ma...@makr.zone]

Like I mentioned earlier, user FlashPackets went down that road, but some problems cropped up with getting back G-code responses, and unfortunately he never reported back, so I don't know if that works.

https://github.com/openpnp/openpnp/issues/1341

[Clemens Koller]

Hi!

You might run into performance issues with your AMD Athlon 7850/4Gb RAM.
OpenPNP is likely not affected by LinuxCNC but for it's image processing
capabilitied I would recommend a more capable system with i.e. 4+ cores
and 8+GB RAM. Your Notebook might do, if it's spare.

I would not risk to spend too much time/work/effort into fixing possible issues
with old hardware and just get a new or additional system.

Used Small Form Farcor Computers are really cheap in the refurbished market,
why not add a dedicated system just for OpenPnP?
I just got some Intel Gen6 Small Form Factor (SFF) system, some i5 6700U?
for 50..100 EUR. Fujitsu, Lenovo, Dell, ... all fully supported by Linux.

In your case, I would be careful if you intend to move the LinuxCNC stuff
over to different hardware, in case it is using some realtime extensions
of the/that specific Linux Kernel. Maybe you want to keep that system
untouched until it's proven stable on another / new system.

Regards,

Clemens

On 12/1/22 05:48, jbasia wrote:
> My old PnP (with proprietary software) is running on Windows 7. A new controller is in the planning (already ordered). Obviously Windows 7 is out.
>
> Hardware:
> AMD Athlon 7850/4Gb RAM (probably from 2009)
>
> That PC has a partition with an older LinuxCNC (from ~2018 I guess)
>
> Is that PC even suitable for OpenPnP? Can OpenPnP run on LinuxCNC? (My mill is connected via parallel port - mill and PnP will not run at the same time)
>
> It's my understanding that LinuxCNC is an O/S and does 'things' to Linux that may (or may not) effect OpenPnP.
>
> Alternative would be to have OpenPnP on a different partition with its own O/S (also no problem) - what O/S would be suitable (considering the age of the hardware)?
>
> If that hardware is totally unsuitable I still have a modern i5 Win10 Notebook
>

> --
> You received this message because you are subscribed to the Google Groups "OpenPnP" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7a2bc85b-f79c-4a88-a405-7fff3ae918efn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/7a2bc85b-f79c-4a88-a405-7fff3ae918efn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[jbasia]

On Tuesday, 6 December 2022 at 23:11:16 UTC+8 Clemens Koller wrote:

Hi!

You might run into performance issues with your AMD Athlon 7850/4Gb RAM.
OpenPNP is likely not affected by LinuxCNC but for it's image processing
capabilitied I would recommend a more capable system with i.e. 4+ cores
and 8+GB RAM. Your Notebook might do, if it's spare.

 Meanwhile I found a few more PC-6400 RAM sticks and can make that machine to a powerful 8Gb RAM PC (very powerful was a joke)

With that I can do the basic setup, if vision has problems I can look into that later, maybe with a new PC. I still like one PC for the PnP and the CNC mill (one PC, probably 2 O/S, this is fine). For Mini-PC, Notebooks etc the problem is that my ol' CNC is connected to a parallel port - even my very old hardware does not have Mobo with parallel port and I have a parallel card plugin. I could probably kick out that controller too and go USB, but right now  I keep the focus on the PnP. 

[justin White]

Curious If anything ever came of this. I'm just getting into OpenPnP looking to build a small machine but I've been a LinuxCNC user for years. There's a couple of wrong assumptions about LinuxCNC in the thread I think. One is that "it's old, for old computers" that's not true. While initially it aimed at parallel ports and software stepping when PCs were a bit more capable of doing that, it now (mostly) uses the Preempt-RT linux kernel and the controllers are typically Mesa cards over ethernet, there's some MCU stuff making it's way in as well but new controllers are being added all the time. They don't use USB in LinuxCNC because a USB port can never be considered a real-time interface. Where I -think- Marlin and Smoothie type firmware's just interpret Gcode on the MCU and handle the motion control, LinuxCNC's controllers only do the actual step generation/encoder counting type stuff and PC does the trajectory planning and Gcode interpretation. All of LinuxCNC's arc blending/trajectory planning stuff is typically far superior to what the 3d printer type controllers do.

Not sure how relevant more advanced trajectory planning is to a typical PNP machine, but there was a fork of LinuxCNC that pretty much died a few years back called Machinekit. These guys came up with some great stuff but I believe it died because they focused on smaller stuff like Beaglebones. One of the better features of Machinekit was that they detached the HAL portion from the "CNC" portion of LinuxCNC. The idea there was that the CNC side ran the UI and control stuff on anything with decent graphics to remotely control the HAL side which could be run on any small linux capable CPU, raspberry PI....whatever. The HAL side runs the RT kernel and communicates with the motion controller.

It sounds complicated but it's actually perfect for something like a PNP because OpenPNP could basically just be a MK/LinuxCNC GUI with all of the vision stuff and whatever it does to adjust offsets running on the CNC side and the HAL side could be as simple as a BeagleBone Black which has it's own PRUs which are basically the motion controller MCU all in a single SOC. I was more interested in what they did with MKSOCFPGA where they took FPGAs with built in ARM CPUs and ran either the full or split version of Machinekit on the CPU and the FPGA portion was ran a ported MESA Firmware. I was enamored by this idea and I made a hardware PCB for a DE10 Nano. I was doing some testing with it and it actually performed great driving steppers and counting encoders at high speeds. I wound up abandoning it when it became obvious that MK was dying and LinuxCNC was not going to port this back into their own project

[mark maker]

While this is all very interesting academically, and certainly fascinating to explore in itself if that is your actual focus, it is simply not a straight way to a solution in Pick and Place.

_Mark

--
You received this message because you are subscribed to a topic in the Google Groups "OpenPnP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openpnp/y9mnpG-YXOI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/791c0e49-2e94-44c5-97c3-f0a9cdafc832n%40googlegroups.com.

[justin White]

So I got my machine to the point where I'm installing OpenPnP on the embedded PC and I'm using a BTT Octopus as I understand Marlin is supported. I was setting up Marlin and I hate to sound....whatever, but Marlin is crap to configure. I did manage to get some firmware built that I configured for the PnP but 3dprinting is so ingrained in Marlin that it's just a bear to try to weed out those configuration files.

So back to this....The implementation of controlling linuxcnc through it's telnet server seems like a winner. I've setup many LinuxCNC machines so I doubt I would have any trouble on that side but being that I currently know very little about openpnp I would struggle with the gcode driver.

This almost seems like a no-brainer. LinuxCNC has access to higher end motion controllers, namely from Mesa Electronics but nowadays it even has an open source firmware called Remora for 3d-printer type boards like the Octopus I currently have wired up in this thing. I'd run both LinuxCNC and OpenPnP on the same embedded PC and pipe OpenPnP into linuxCNC through a local port. Question is, is anyone willing to help with the gcode driver?

[dc42]

You can also run RepRapFirmware on BTT Octopus boards, see https://teamgloomy.github.io/. The configuration is read from a file on the SD card at start-up, so you don't need to build the firmware yourself.

[justin White]

I looked into it a bit, looks like that RepRap firmware does not support the 446 version of the STM32. Looks like it has something to do with the RAM size.

It's not really so much about building the firmware, like I said I have built Marlin although once I get it somewhat working I'll have to go back and get everything else working. It just seems like the effort would be better spent somewhere else.

On a 3D printer I get this type of firmware, it makes sense. On a machine running OpenPnP you already have to run a fairly reasonable PC just to handle all the OpenCV stuff so it doesn't seem like the greatest use of resources to run a motion controller firmware that pretty much asks the MCU to do everything motion related. LinuxCNCs approach is to handle all of the trajectory planning on the PC and let the motion controller just worry about the hard realtime tasks like step generation and encoder counting. For the OpenPnP cost of basically just writing a gcode driver with the proper syntax that's happy with LinuxCNC it just seems like a better route to go, especially considering you can presumably still use alot of the 3D printer boards

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d1e3b53f-2521-460a-ad36-d8fb39683683n%40googlegroups.com.

[justin White]

Sorry, meant to say the problem with Reprap and the 446 MCU is the flash size

[bert shivaan]

what format does it need to look like going to LinuxCNC?

The gcode driver is REALLY versatile in respect to being able to send really any stringent out almost any port I think.

You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQ02MPP_gVjVZ%3D4VEgpP8c7oMini7jeLX6OR79zTntEdngqmw%40mail.gmail.com.

[justin White]

Well that's one area I'm not super familiar with yet. As mentioned a few posts back, someone did try to get it started with some limited success. https://github.com/openpnp/openpnp/issues/1341#issuecomment-986319188

I've never used the linuxcncrsh which is basically the remote server for it. The MDI interface in a typical GUI based LinuxCNC install doesn't require any funny business Gcodes are just direct. Apparently there's some message setup business in linuxcncrsh that has to be sorted out. Is there any documentation on setting up a gcode driver in OpenPnP? The configuration/firmware side of LinuxCNC should not be a problem for me. It's just this communication angle between OpenPnP and LinuxCNC that I'm pretty fuzzy on yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BKNHNykg7aZG5YW7KjsQaQNZcqU%3DxdcHPyGmYWH%3DS_gNgyCgg%40mail.gmail.com.