Advanced Search

I working also on 2 other new boards:

1. 3Axis adapter-board with NEMA17 drivers for the iceBreaker Devboards 


2. own FPGA-Board with ice40uP5k and 6Axis as Raspberry-Hat (hope it works ):


both can be build, flashed and connect directly from the RaspberryPi via SPI

 

I couldn't get the parallel port tester to work (as in it complained about a ton of Python code when I executed it, and I did modify the port from 0x378 to 0xd010 in ptest.hal). When I said:

"That said, when I went to check the outputs on a scope, it seemed kind of weird. Pin 1 was high all the time, but Pins 8, 9, and 14 were low. I tried putting "invert" on all 4 pins, and they all read low. So I suspect there is still an issue outputing out of the parallel port."

I meant I had the cable plugged into the computer but not the controller and had an oscilloscope on the pins. It is of course possible the cable is not fully populated with wires or that the wires are twisted. I find it interesting that with the default configuration the Z axis seemed to work, and I think the only difference was that the enable signal for it was "A Step" and the new one is "EStop On". So perhaps Pin 8 on the cable isn't Pin 8 on the port. I'll try to ohm out the cable and establish continuity across the pins.

Given that I never saw Pin 8 go high (at least in the configuration you gave me), I think it's unlikely the controller is to blame.

As a side note, for reasons I don't understand I seem to still have to uninstall and reinstall parport_pc.ko after each reboot to get the port back.

I don't think it would be that hard in HAL.

This will also stop the spindle if the pressure falls, which probably isn't desirable, so you could add a latch:
linuxcnc.org/docs/stable/html/man/man9/flipflop.9.html

in addition to (most of) the above

This will turn the spindle motor on when there is pressure and the spindle is on, but will only turn the motor off when the spindle-off (inverted spindle on) goes true and resets the latch.

If you want an alarm too, then that would be based on the latched output being on, and the pressure being low.
Add another not, used to create an output that is high when the pressure is low, and another and2
linuxcnc.org/docs/stable/html/man/man9/message.9.html

Probekins wasn't entirely succesful, so might not be the best way to achieve what you want.

If doing the same thing now, I think that I would bas it around external_offsets, not kinematics.

I don't think it matters what is flat and what is bowed, probekins will apply the correction in the right direction. The effect of both is identical.

If you need .001mm accuracy for the entire servo loop at speeds in excess of 10000mm/m then you should choose a different control software, and drive OEM.

Here is an actual scenario used in PNP(Pick and Place) for the chip making industry.

Positional accuracy and net velocity is desired at .002mm at 60000mm/m. In their controllers the servo positional update is sent every 1ms in .001mm increments in a point to point program. This is done using highly tuned and regulated hardware for the specific application.

CNC milling or turning does not need that level of granularity as feed rates/velocity is usually below 30000mm/m and rarely send point to point moves at .002 or below as the moves are typically highly coordinated multi axis moves such as a 3 axis arc move. This means that a 1ms tick cycle is more than enough to maintain a solid coordinated move within a volumetric accuracy of .002mm.. if one chooses a solid drive/motor/machine setup that can manage that granularity.

LCNC is hobby grade with some really cool features. But hobby grade none the less. Therefore, if you expect to see the performance of the chip machine you cannot use LCNC. The mixture of OS, Ethernet driver, and software stack limit the granularity of position to a velocity @ or near 30000mm/m. Above that and you will see the positional accuracy lower and repeatability suffer. And that is further disrupted by the rigidity of the mechanics and motor tuning. Remember that a servo drive position has a settling time, Acc/Dec, and following error. All are effected by the load inertia and capability of the drive to sufficiently recognize the error in cmd/act position and adjust while maintaining P/T. Many modern drives have such ability but as the ability grows so does the cost.

Yes XYZAC, XYZBC need different kinematics. For the math and calculating the tool direction in opencascade i just
thought use the letters A & B. At this stage the kinematics are not solved. Only the tool tcp & tool direction is then solved.
Do you think this is ok?

If you want to handle the specific kinematics separately then maybe it would be more generic to calculate smoothed tool orientation as a unit vector (ie length = 1) with origin at (x,y,z)=(0,0,0).
1. Calculate the vector pointing from smooth TCP knot to smooth TA/TO knot
2. Translate this vector to (x,y,z)= (0,0,0,) (ie subtract smooth TCP knot coordinates from start and end points)
3. Normalize the vector to get a length of 1. 

To get the specific tool orientation angles we could parse the ini file to find out which rotary joints are available and calculate the appropriate angles (ie A,B or C ) from this orientation vector using 'atan2' function. I have done some work that calculates spindle rotary orientations from a given tool orientation vector, although that was in python. There will likely be some issues with rotation directions and joint limits that I had to deal with but if  your algo spits out the orientation as a vector then this could all be handled separately.

I true ECAT controller can use all 3 modes. Pos, Vel, and Tor. LCNC only truly supports Pos mode. That is the only limitation from LCNC. Based on the timing charts from EtherLabs best performance will be an open control/drive loop for Pos control only for the control side.

The balance of the performance is application specific to the user. It is up to the end user to build a properly configured mechanical drive and tune the motor drive combo to the setup you create.

Hello,
I'd like to say that I've managed to figure what the problem was. The devil is really hidden in the details. The product ID in the DeMS300 was set to the older CMM-EC01 module. I figured it while I was tinkering with the generic Cia402 slave. I just changed the PID in the lcec_ms300.h and recompiled the LCEC. No initCmds were needed.

Best regards!

This is true. But, no matter what as stated in most ECAT drive manuals they have a 1Khz servo update cycle. Which is the same rate as the tick cycle. Furthermore, 1Khz is more than sufficient as the drive~controller is not a closed loop system. This tick cycle at 1Khz has been used for well over a decade with success. Enough that ECAT is nearly the standard protocol.

Your limitation is neither LCNC or ECAT. Your limitation is hardware choice and understanding how to get your drive to perform based on your end effect loads or in the case of your initial question, no load.

ECAT is a protocol. A standard method of communication. Meaning, it is what it is out the box for a reason. You can have 50Ghz servo threads, and 50Ghz servo update in the drive, but the frame rate for the protocol will still be 1ms. Period.

Hi Arciera,

Yes XYZAC, XYZBC need different kinematics. For the math and calculating the tool direction in opencascade i just
thought use the letters A & B. At this stage the kinematics are not solved. Only the tool tcp & tool direction is then solved.
Do you think this is ok?

I'm still a bit confused seeing that tool motion still decelerates to a full stop after each segment.
In the video i speak about a first test without any motion logic for hal-core. Stopping motion at each gcode line.
Next step now is to add g64 fillets to the gcode. Then eventually the look ahead add's end velocity where it can.

That is okay for ECAT or Mesa.

That is 125 nano seconds not milli seconds. Or 1/8th of the ECAT tick cycle standard. That leaves more than enough time for the TP to calculate and form ECAT frames in the proper order and respond to incoming requests or updates such ACT VEL and ACT POS to update the planner. This is not your problem.

ECAT is a sync distributed clock frame bus. It is by ECAT standard fixed for specific reasons. The most important is determinism. ECAT motion control was designed for smart peripherals that no how to make cakes, nice and perfect cakes. It just needs a steady stream of how many and and how fast do the cakes need to deliver. The drive, if of decent quality should be more than capable to do this. ECAT for CNC is a very mature setup and requires very little "tuning" for the frames. What does need tuning is you motor/drive/machine.

Since ECAT in LCNC is only fully functional in CMD POS mode, you must tune your drives to match the return loop of your motor/drive. In your manual it gives a fairly detailed description of the parameters that are used in that mode. The TP and POS Loop will ONLY use those parameters. Typically, these are FF related needing gains to be adjusted for higher or lower inertial loads. You can try all the other parameters but, in the diagram for your drive you will see that in CP mode very few are used. But, if the drive is mature in the ECAT eco-system this mode will typically see better results than any S/D Mesa setup due to the internal TP and the true real time within the drive. Yes, ECAT drives have their own internal motion controller. Like a Mesa card in each drive only better.

It is not complicated. It just gets complicated when you look at ECAT on any CNC as a method to control motion using old and outdated concepts. Very few major CNC control OEM's use the fully closed loop system through the CNC control. They offload and create separation of concerns so that if the CPU needs to update the UI, it can without interfering in the overall thread. In fact, Siemens CNC controls have 3 separate buses. UI bus, NCK bus, and motion bus. Each has it's own isolated stream and communicated via a single shared data exchange in a Pub/Sub setup.

If you want to try and use LCNC to control the actual motion of your motors, use a Mesa with full closed loop control.

Hi, i was solving issue with raspberry pi 5 with guys at etherlab, and from my understanding 1ms or 1kHz ethercat cycle is limit for genetric driver. You can get faster cycles when using native drivers like e1000 or igb for intel based ethernet cards.

gitlab.com/etherlab.org/ethercat/-/issues/104#note_1772346704

EtherCat is 1 ms. tick cycle or 1Khz for the frame cycle. EtherCat in LCNC is more a 800~900hz so there is a slight lag but the DC will always sync to the first clock in the first peripheral. From then on all DC on all devices will be offset to sync with the known clock derived from the first device.

Etherlabs EtherCat explains this in the docs.

So regardless of servo thread rate, the EtherCat frame cycle will find its own clock rate to update the drives. As I have stated in prior posts, EtherCat in LCNC is a quasi real time version. It is functional to the mid app level. If you exceed 1500IPM in simult axis control, accuracy may suffer. Or the driver will drop the comms and error due to overload in the frame buffer.

I was just posting that but then got distracted.
I feel that too many are ready to jump to the latest kernel without really testing.

Probably by remaping M3 would be the best way, but no idea if M3 can be remaped.
I am sure it can be done in hal but that is quite a journey.
Using M6 or M7 is much easier, see mist/coolant use, requires adding an output for it in wizard, be it StepConf or PncConf.