FPGA (field programmable gate array) programmed for linuxcnc motion

I'm guessing you are new to FPGAs from what you write. Before you order an eval board, look at their SoC versions - rather than implementing a soft processor in code, they come with a an actual dual core ARM hard processor in silicon.

You're going to want to implement Linux on it - and wire it up to all the high speed FPGA stuff. That's a tall order unless you are a hardened FPGA specialist and more.

Let us know how you get on.

Hi
I wrote my own FPGA code in VHDL years ago to support time critical hardware in Xilynx CPLDs (yes I still own stock in the company). I will tell you right now unless you are a specialist or need > 1000 units per year just buy MESA hardware and ask PCW to help out with your custom application ( my MESA hardware, firmware and software works far better than than my own application layer software layer that I write does and I cut a lot of thin sheet sheet, read very touchy height control with full ( sorry to keep you guys up dated but my system is now working far better than my commercial system ever did,i internal LCNC Z axis control). Seriously I know you are into serial manufacturing but how many plasma systems do you actually ship in a year? The Proma approach is seriously out of date.

Sorry my real aim is to get everyone here to work together to produce a world class LCNC plasma solution.

John

Hi Islander, do you currently use the linux external offset branche from mr. Garret for your THC control?
I like to make a fpga board for hobby purposes at first in the evening hours. It would be great to use a pci express slot
and make here a fpga chip on running with a few step and dir signals. If it is to hard to do, i will stop that process, but i like
to know if i can do that.

Hi Muzzer, yes new to fpga. I want only a pci express connection from my linux pc to the chip and after that a free configure multi output setup. Pci express looks like a mesa setup. But it may also be a ethernet or etercat setup. For me depending on speed and difficulty to get things working.

In beginning i see the fpga chip now only as free configurable hardware layer to use with linux. At this moment i don't think i will put software on this chip like linux...
For example, if i have 50 outputs and 50 inputs. I can make unlimited configurations to use. If you have 8 inputs that behave like dip switches, it is easy for beginners to change the settings with bit control.
It seems nice for me to start with the existing parport driver, and build after that the chip on a modified sunix ltp1 card to test with.
But that is an idea i now have.

Hi Rodw, yes you are right. But it is also important to do things in life, you like to do. This is a kind of hobby for me.
I tested linuxcnc on a hd plasma, but i had some problem's. Soon i will be able to solve a few problems on a new test machine.
I will let you know.

One of my problems is the height measuring macro of linuxcnc (touch off). You see this measuring distance back in your gremlin screen. My measuring default was 100mm. This distance you see back in your gremlin screen. It is actually a problem to solve.
I can make picture if not clear.

Other problem is arc on signal. Okey machine is waiting on "arc on" signal at start for the g-code input seconds you want. "P4" is 4 seconds. So far so good.
But if arc is lost during cutting, machine is not stopping..... So i must make a solution for this, like interrupt code. But this must
be hard coded i think during compiling linuxcnc.... But maybe i can use the emergency input for this with a little python code...
But that can be building on a code you don't want to use for that purpose.

Now i think about mr. Morley he can say this :

But that can be building on a code you don't want to use for that purpose.

So master, so student.

From student to teacher :

Python can do sha265, but can it do also free nesting?

Grotius

While I am still running my plasma table on an external offsets build I am not using any of the features for torch height control. I am actually planning on moving back to the straight master branch next week when I get some time. I never could get good THC using the external offsets branch and the eoffset_pid component. Right now I am using hal components to build a THC solution that works far better than the commercial system I have ever did. That said it still isn't perfect but getting close. For thicker materials and lower speeds, or if you have high powered servos driving your table this will work really well. My table is power limited because of the 3.5Nm steppers used for the axis drives and the high cutting speed, 5.588m/min. Now the solution I have isn't perfect but I welcome any chance to discuss it with you and Rod. I will be able to devote some time to this next week.

I am a real big fan of using a galvanic isolated connection (Ethernet) between the control computer and all the plasma table stuff, that is why I am using 7I76E and THCad cards. To me any PCI connection will eventually have problems in a plasma system.

John

islander261 wrote: While I am still running my plasma table on an external offsets build I am not using any of the features for torch height control. I am actually planning on moving back to the straight master branch next week when I get some time. I never could get good THC using the external offsets branch and the eoffset_pid component. Right now I am using hal components to build a THC solution that works far better than the commercial system I have ever did.

I am a bit confused by this. The external offsets branch ought to be a better way to apply the offsets, even if your HAL components setup is a better way to calculate the offsets. Using External-Offfsets also should guarantee that the machine stays within the travel and velocity/accel limits.

If you are finding that an alternative way to apply the offsets is working better then perhaps you have not set up the external-offsets limits optimally?

Andy,

I think a few of us have given the external offsets a good workout for plasma (3 I know of) and we could never get it to get good control of the torch height. The best I could get was when Dewey had missed something with metric v's imperial and we had some settings out by a factor of 25.4. (I seem to remember you thought it was running like a drunken sailor) Dewey has since added a deadband to his hpid component at my suggestion but I've been lazy (or busy) and have not tested it. I feel a bit guilty becasue Dewey has put so much work into helping me understand such a complex subject and taking my feedback and putting it back into the eoffsets branch.

Anyway, maybe this weekend as I've got a bit of a lull for a change.