Advanced Search

Hi,thank you so much .as what you described,it looks that I still need hardware to support to use the open-loop stepper,such as a ethercat controller .I think you are right .Even if I bought the ethercat controller,I still dont know how to config the specific device.So,to the software part,would you share me a sample code or some resource link that I can used for make the open-loop stepper work? I'll appreciate that,many thanks again !

Is this problem an error or has the page been discontinued? Until last week I was using it, for me this page was very useful because I saw how to implement each component

Try moving the 'loadusr' line to your postgui.hal

If you think that the control cabinet will be too small, them you are bound to be right. (In fact, it's probably too small even if you don't think it is)
Maybe if you take out the diagonal braces that interfere with a bigger cabinet you can use the control cabinet itself to brace that face?

Mañana le envio los archivos de ejemplo para usar los macros.

That error will appear anytime you press a button to do something while the interpreter (gcode) is running or machine is paused.
And do provide more info when asking here, please.
Thank you.

Word of caution, never use Office suits to edit machine files, use only text editors like Marvin mentioned, or GEdit, XED, mousepad, geany, nano, etc

I would really, really avoid using those boards on a big machine especially with analog drives/motors.
And Mesa has available boards for analog systems, just not the usual ones like 7i77 and 7i97, so you can get a Mesa 7i92 OR 7i96S and a 7i83 and 7i85, that should be all, except if you need more IO, then add a 7i84.

Sorry but i can not figure out anything from that video, can you do one while moving under power?
And are those stepper or servo motors?
I have to ask as ClearPath servos were not servos at all a few years back, just steppers, some with encoders.

I did some prodding of the interfaces over the weekend. This machine has two auxilliary I/O boards called the "AUF" (auxilliary functions) and the "LCTCAUF" (Low Cost Tool Change AUF), both of which are connected over serial. The maint manual describes the interface to these but there are already some discrepancies. The manual said they were 9600 bps and used RS485 in a multidrop config. They clearly use 38400bps and are RS422 with independent TX/RX pairs to either board. The boards appear to support RS485 but this machine doesn't use that configuration. If more than two are required maybe it was supported.

In any case the protocol was not as obvious as I was hoping. In both cases the units send packets to each other that start with a unique packet magic byte (0x23 or 0x29 for the AUF and 0x26 for the LCTLAUF), payload bytes that all appear to be 0x3_ or 0x6_ and some sort of checksum byte that is always 0x4_. The packets are firing at about 50Hz. The 4 bit "checksum" appears to be additive in some way but I have not been able to discern the algorithm used. Turning the coolant on off caused a single bit to flip on the outbound packet to the AUF as well as a change in the checksum byte. The LCTLAUF has a fairly small outbound packet but also has a counter in the packets for some reason. Decoding all the error states in particular might be a challenge. An AUF packets at startup for the curious:
 

Although elegant to reverse engineer these and have a "wiring free" conversion I'm sure it would be easier to replace or modify these boards with Mesa Smart Serial I/O endpoints. It is quite nice to be able to switch back and force between controls though easily especially if the conversion takes a while. Something to ponder.

Can you plot the current error along with velocity?
(position is not really useful for this kind of tuning)

FF2 is use to reduce the error during acceleration
if the "spike" duration is the same as the period of
acceleration you should be able to tune this out.
(if you add too much FF2 you can make the spike reverse)

If the spike is only at the beginning and end of the acceleration
phases, this represents delays in the command --> feed back
in the system and the physical limitations in the drive/motor
hardware (its not possible to have a step acceleration function)

Delays may be cured by drive setup (for example any input filtering
should be minimized)

The delay and drive/motor physical limit issues can be worked
around a bit by lowering acceleration. A better solution is to use a
jerk limited trajectory planner. There is some ongoing work on this:

forum.linuxcnc.org/38-general-linuxcnc-q...ner-using-ruckig-lib
 

If you are talking about the "j3 bewegungsende im referenzstatus 7" error
That is not specifically hardware related but seems related to the homing
configuration.

Can you post your current  hal/ini files?
 

serrepattes wrote:

La configuration des IO ne doit pas être faite dans pncconf?
 

I think that pncconf can do it, but I assume you have already tried that?

 

You may be able to use pncconfs discovery option to allow setting up
the additional encoders.

You do need to use 7I96S firmware that supports the 7I89, that would be:

7i96s_7i89d.bin
 

Hi,somehow my probe basic screen won´t load my classicladder project.
This how i load it in the main hal file.
loadrt classicladder_rt
addf classicladder.0.refresh servo-thread
loadusr classicladder probe_basic.clp

In Axis or gmoccapy it loads it correct.
in Probe Basic, the classicladder editor tells me "can´t load project"
When i load it manual in the editor it works.  

Has probe basic some special classicladder loading requirements?