Advanced Search

rodw, probably a coincidence but 400 rpm = 6,67 rps. 5mm per rev gives 33.33 mm/s which is
awfully close to your MAX_VELOCITY in the ini file.
Happy you got it to work.
I find one learn a lot by messing around and trying to solve issues, real or not.
Here I got to practise setting the controlword manually

Still the issue with position feedback during homing, right?

NWE wrote:

My order showed up today! 

Great! 2 idiots now! So just to be sure you are using my latest XML without the torque pins and dominic's cia402.comp component?
That works. My stuff is going back to the drawing board

NWE, with controlword at 15 set op-mode to 8 (csp) and try to move again.
Don't move a lot at once, it can overwhelm the drive. Linuxcnc moves just a tiny distance every servo cycle.
Should see it on position feedback.

Hmm, once I plugged the Y axis in to the drive, everything is working perfectly on all drives. Sometimes I am an idiot!
Something funny going on. The maximum speed I can get out of this is around 400 rpm. Thats simple square wave arduino territory. I know I can get 800 rpm out of a similar drive on a Mesa card and a DM542a stepper driver. I have driven the same stepper motors out to 1000-1500 rpm and more in the past.

My ini file (attached) is set up for a metric machine using a Mod 1.5 40 tooth pinion and a 5:1 gearbox.
That equates to a 60mm diameter pinion (1.5x40) with a circumference of 188.49559mm divide by 5 and we have 37.69911 mm per rev, = scale of 265.25 steps per mm based on Lichuan's default 10,000 steps per rev.
I've tested this with G1 x188.49 F2000 and it moves exactly 5 revs on the bench. 
Time to dig a bit deper into the  Lichuan config program which means I have to boot windows uggg!

So its been a long way to get there but you guys are good to go with Dominic's component, this in i file and my hal file in my last post!

My order showed up today! 

I tried a minimal hal test in the terminal. I can power up each of the 4 motors, I set control word 6, 7, 15, each motor's shaft locks when I reach 15. But I didn't get anything to move yet. Not even the first motor. I didn't try the cia402 yet.

For my ethercat-conf.xml I directly copied from rodw's post above. The only thing I changed on it was the filename.

I did an industrial project 5 years ago with the same control model as you are describing. I am by trade an industrial controls/mechanical engineer and I was contacted by a medical company seeking to automate the production of one of their products. After evaluation of the system requirements it was clear that one aspect of the system would need a CNC controller to run a 4 axis ultrasonic cutter while the bulk of the machine would require standard PLC controller elements. In addition to the CNC cutter section, the machine has 4 servo driven custom conveyors, a heat press laminator, various air cylinders, and a PID temp controlled 10KW heater platen.  It also uses an overhead projector that loads recipe driven images to direct the machine operator where to locate the raw materials on a circulating pallet.

The single most important requirement of the customer was that they wanted a machine that would be simple to operate so that the training to run the machine would be minimal.

I  reached out to this forum to help me understand what would be the best method to "blend" traditional industrial controls (PLCs, VFDs, HMIs, sensors, etc.) with LinuxCNC. Eventually, I landed on using Python as a "bridge" between LinuxCNC and the PLC/HMI. Python has an excellent and stable module called pymodbusTCP. With that module, python can reliably talk to virtually any industrial PLC or device that speaks modbus. The second module that makes it all work is the python linuxCNC module. It talks to a running instance of LinuxCNC and can get status information and it can command LinuxCNC . Using this custom python script that I wrote the system works without the machine operator having any knowledge of how to run a CNC machine or any G code whatsoever. When the system starts up, the python software bridge homes the CNC system and checks it for ready status. The operator simply selects which product code to run via the HMI. From there, the PLC tag with the product code is read by python through ModbusTCP. Then, the correct G-Code file for that cut pattern is automatically loaded into LinuxCNC. When the product leaves the laminator and arrives at the CNC cutter the PLC sets a bit that python reads. Python then tells LinuxCNC to run the G-Code file and it cuts the parts out. When LinuxCNC completes the cut cycle python gets the complete status bit and then it sets a bit in the PLC that lets the PLC know it's time to move the pallet to the next station.  The operator has zero direct interaction with LinuxCNC. This system has been running now for over 4 years and it runs every day producing thousands and thousands of parts. The customer is totally satisfied with the machine and they are now starting to talk to me about the need for a second one. Based on my experience, blending LinuxCNC with standard industrial controls methods and devices is an excellent way to achieve advanced machine control systems. I would highly recommend using Mesa Ethernet cards to offload the pulse generation from your LinuxCNC installation. The Mesa card I installed on this system has been flawless.

Edit: Modbus (TCP) may not be the most "modern" approach that is available but I would say that it is the most universal, well understood, and common Industrial protocol. When it comes to system support it would be hard to argue against Modbus just because so many industrial control techs know it and use it. Simple system architecture typically translates to reliability. In an industrial application, reliability is king.

ohh yes,
I was searching for hm2_7i96s.0.*
But I used addf [HMOT](CARD0).read of my .ini variables in the beginning of my .hal file.
I will check it before work

Muecke wrote:

What surprises me a little is that when the forum is unavailable, the other areas remain online without any problems.

hosted on a different server, if I'm correct:

$ dig www.linuxcnc.org
-- snip --
linuxcnc.org.        557    IN    A    69.163.143.134

​​​​​​​$ dig wiki.linuxcnc.org
-- snip --
wiki.linuxcnc.org.    1038    IN    A    69.163.143.134

$ dig forum.linuxcnc.org
-- snip --
forum.linuxcnc.org.    1988    IN    A    162.243.45.186

Hakan wrote:

Yes it has been going on for a long time.
Very long latency, it is almost like it isn't using a RT kernel.
 

What surprises me a little is that when the forum is unavailable, the other areas remain online without any problems.
These include, among others:
* Downloads
* Search
* Documents
* Archives
* Community
* Wiki
* Source

This leads me to believe that it is actually only the forum itself that has a glitch and that the entire platform is not affected.

//
Was mich etwas verwundert: Wenn das Forum nicht erreichbar ist, sind die anderen Bereiche weiterhin problemlos online.
Dazu zählen unter anderem:
* Downloads
* Search
* Documents
* Archives
* Community
* Wiki
* Source

Das lässt mich vermuten, dass tatsächlich nur das Forum selbst eine Macke hat und nicht die komplette Plattform betroffen ist.

Thank you so much !!!

That works.

Oh ja, das hochgeladene Foto sieht tatsächlich ziemlich leer aus. Ich wollte das aber eher allgemein ausdrücken – zumindest so, wie ich es bisher aus Videos kenne.

Was mir aktuell noch fehlt, ist eine vernünftige Dokumentation. Mit kryptischen Dateien kann ich ehrlich gesagt nicht viel anfangen, wenn nicht klar erklärt ist, was was bedeutet und wie man welche Einstellungen vornimmt. Genau deshalb bin ich gerade stark am Überlegen, ob ein Umstieg für mich wirklich sinnvoll ist oder nicht.

Reizvoll finde ich das Ganze auf jeden Fall.

Einerseits mag ich es sehr, wenn ich meine Schalter direkt an der Hardware habe, diese entsprechend einstelle und die Kiste dann einfach funktioniert. Andererseits hat es auch seinen Reiz, alles über die Konfiguration am PC zu machen – allein schon, weil dann niemand versehentlich etwas an der Anlage verstellen kann. Das hat natürlich Vor- und Nachteile:
Wenn ich z. B. einen Treiber tauschen muss oder möchte, dann muss die komplette Konfiguration softwareseitig angepasst werden und nicht direkt am Treiber (Hardware selbst). Der Aufwand dürfte dann deutlich größer sein, schätze ich.

Aktuell spiele ich mit dem Gedanken, mir eine gebrauchte EL8 zu besorgen und damit einfach ein bisschen zu experimentieren. Das wäre vermutlich der beste Weg, um Erfahrung zu sammeln und die Lage realistisch einschätzen zu können.

Hal.h in install image seems not to match hal.h in GitHub? I'm trying to modify the streamer component when I call it normally with no changes it works when I recompile and install the source code from github with no changes at all it refuses to run the function hal_export_functf that function is in hal.h on GitHub, but not in hal.h on the install image, that one only has hal_export_funct why is that and what should i do?
 

In a terminal:

Have been working on the S-curve, even when not posting here, YangYang is going to merge Ruckig, will see how mantainers react, it is MIT license, so we should be good, we don't need the pro version, and YangYang can fix it if needed, probably next week update on planner type 1
As for Planner Type 2 progress continues, I am now done with Feed Override phase, doing some cleaning up, and moving to Blending soon, arcs are working from curve9 from Tormach, planner type 2 also has ruckig but in uspace, which makes some things a bit more complex.
Progress is ongoing, thank you all for the support, and the testing, there will be new release to test probably next week.

Looks like the Trixie issues repo got nuked, does anyone know what happened?