Advanced Search

Aciera
SOLVED: Now its running!
Thanks a ton!
greez
chris

Sadly, it doesn't look like it's the cable. Multimeter says all pins are connected and not twisted (I didn't exhaustively ook for internal shorts, maybe I should check that, but seems unlikely).

I'll try the default configuration file and see if Z axis functionality is restored and then compare the files.

Donb9261 wrote:

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.

Ethercat cycle time should be shorter then 1ms but have to be longer than control scan time which has linuxcnc on correct hardware ... there is DC sync setup in the slaves and for drivers are multiplies of 250us times... therefore if lcnc scan time we change to 250000ns and calculations will be done, next we can change in the ethercat-conf.xml time to 250000ns and in the slaves too... we can change that time to single time sync period which are 250us... teoretically it should works but I do not have proper hardware for the check correction of this idea right now... 

So, nächstes Problem Touchscreen -
nachdem jetzt mit vielen Fragen und Hilfe von hier die Maschine grundsätzlich funktioniert, habe ich mir einen Touch Monitor angeschafft. Ich war schon drauf gefasst, dass der nicht mit Plug&play einfach so laufen würde, habe aber mit Google nicht gefunden wie man Touch jetzt unter Debian 12 zum Laufen bringt. ICh arbeite unter Mate.
Ich habe ein Lenovo ThinkCentre M92P, iCore5 3470T 2,9 GHz, 8 GB RAM der nur VGA Ausgang hat, und diesen Monitor:
www.viewsonic.com/de/products/sheet/TD2223-2, der auch im System unter Bildschirm erkannt wird.
Habt ihr Ideen dazu? Was muss ich nachinstallieren oder einschalten?
Danke für jede Antwort!
Arno
PS: Natürlich habe ich diesen Thread gefunden, werde aber nicht schlau daraus und außerdem ist der schon wieder 2 J. alt.
forum.linuxcnc.org/18-computer/46729-tou...in-ubuntu-and-debian
Sollte ich danach auch für Debian 12 vorgehen?

Danke, Aciera! Hat funktioniert!

I would think they are proprietary. Techno seemed to make their own hardware if I remember correctly.

What I was hoping for was to go:
Linux PC >> Parallel Port Break out Board >> Existing Driver/Amp Boards >> Existing Cables and Servos.

So basically change the BoB to a LinuxCNC talking board and proceed as if nothing ever happened to the rest of the machine.

I have no idea how practical this is. I will get some pictures.

Err:1 download.opensuse.org/repositories/science:/EtherLab/Debian_12 ./ ethercat-master 1.6.0.gcafd367-1+1.2
404 Not Found [IP: 95.216.238.135 80]
Err:2 mirror.aardsoft.fi/opensuse/repositories...A/EtherLab/Debian_12 ./ linuxcnc-ethercat 1.39.0.g4299f7a-0
404 Not Found [IP: 95.216.238.135 80]
E: Failed to fetch mirror.aardsoft.fi/opensuse/repositories...67-1%2B1.2_arm64.deb 404 Not Found [IP: 95.216.238.135 80]
E: Failed to fetch mirror.aardsoft.fi/opensuse/repositories...g4299f7a-0_arm64.deb 404 Not Found [IP: 95.216.238.135 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

This is what I got, by enter "sudo apt install linuxcnc-ethercat"

Many thanks for the quick and detailed reply. I will try soon.

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.