Advanced Search

The riocore generator seems to be generating a linuxcnc config and hal file entries for servo drives when I'm using steppers in my config. I've got PID params and other things specific to servos appearing in my rio.ini. Is this intended? I'm just using the default config for the IceShield for now.

in the appendix my servostar profibus attempt.
Btw, here are details of my setup:
Servostar 603, Firmware 5.76, HW version 49.01
AKM31E Servomotor

Hello endian,
great, in the end I found somebody who is brave enough to work on the kollmorgen servos! Awesome!
In the appendix, you can find a tarball of my current version. As I said, the drive is somehow communicating with lcnc, but I do have terrible timing issues.

In a nutshell, what I did or tried to do:

set up the EL 6731 using twincat3

• PDOs for parameter channel and process data
• cycle time 1ms
• use of Ethercat MDP Mapping and upload the config to the EL6731, hence no init commands or startup sdos in ethercat.xml on lcnc side necessary (Not sure here)
• not sure about settings for Distributed Clocks (just left it default, at the moment)

lcnc comp

• use parameter channel to set operation mode <--- velocity
• byte swapping magic (not sure If I got that right)
• scaling the velocity and position feedback (not sure about the scaling numbers, docu is a mess, as you probably know

lcnc ini/hal

• try to use a simple PID loop: position command (from motion, setpoint) position-feedback (from servostar. Here I do have the issue -- due to comm problems this data is very laggy, hence the PID cannot do its job) PID output == velocity command to servostar

Here are my issues / todos

• I'm not sure if I correctly use the parameter channel of profibus (PKW) Due to lack of understanding of SDOs, I simply put the PKW as an PDO and initialize the drive on startup -- IMHO it would be better to do that via SDO or some other hard-coded init sequence I'm not aware of. Maybe the constantly send/rec of the parameter channel causes the timing issues.
• I need to parameterize the velocity profile for the position loop. Where to do that? Drive GUI?
• Homing: I think of simply use the built-in homing method of lcnc, the implementation in the hal comp seems to be a bigger time effort. Here a question, in case the homing switch is reached (digital I/O of another EL card) how to set the position feedback of the kollmorgen servo to zero.
• Enable the drive is working, disable is buggy -- need to correct this

Sorry for the lengthy message, but maybe you have some hints on one of the issues. I'll definitly take a look at the other thread and your provided info. Thanks again!

BR Franz

this is canopen for sew lteb vfd which should be workable for non rigid tapping purposes ... I running them 18k low cost spindle just for researching

please post your .ini file

I have done profibus interface too... homing is waiting too but it is not yet tested well because of time .... profibus interface will be same for each of kollrmogen product ... as well as s400, s600, s300 and s700 ... defenetly share your code if it is possible ... I will share them when I will on my second laptop

here is thread where is all necessary stuff for ds402.comp for ethercat interface .. homing will be same in profibus and here in the ethercat .. but with profibus it is more fun with byte swaping for motorolas cpus ... and for ds402.comp is homing and all other functions are working for hw 04.00 and fw 5.13 and higher 

regards

I have finally started to work with LinuxCNC
Tried using the Mach import feature in LinuxCNC but it didn't work very well for me, but I was fortunate enough to have both systems' monitors on the same shelf side by side which resulted in a nearly working LinuxCNC system.

The LinuxCNC system is able to run the home-all routine, but I find that the Z axis goes in the wrong direction, so after home-all I need to enter a positive value (G0 Z10) to get the tool to move towards the workpiece.
This is wrong in my mind, as it should be a negative value like: G0 Z10. 

I find that the X and Y axes work as I thought, it is only Z I have problems with.
What do you think is the error?

 

Many thanks! this sounds way easier than I tought.

A 'queuebuster' is a command that tells the interpreter to stop parsing Gcode until actual code execution has caught up (ie the command queue is empty). After such an event the new ini.* values are reloaded and Gcode parsing restarts.

The queue buster (eg reading an analog input) needs to be right after the change
in the ini values (eg done in the 'M123'). I usually put a queue buster in front as well:

Aciera wrote:

The underlying problem may be that GUIs handle this differently (ie have not been updated to the new [SPINDLE_n] section) but I'm not sure.

Please raise an issue so it does not get lost.
 

I have raised an issue here: github.com/LinuxCNC/linuxcnc/issues/3171

I vaguely remembered there being a discussion about this and I just found it. This may explain some of the issues:
github.com/LinuxCNC/linuxcnc/issues/2335

Thanks that already helped a lot.
linking and unlinking Hal I can mange in a bash script.
I would switch reference and limit switch for toolchenge and Bach afterwards.
What I don't understand is the queuebuster command.
What I understand ist the the limits are part of the milltask an I can alter the values with halcmd without altering the infile.
Where and how do I need the queuebuster?

Thanks

Patrick

JT wrote:

Many of the later GUI's introduced a ton of extra ini settings, the authors of those GUI's should update the docs if they moved from display to spindle. I really don't understand why they didn't use the existing ini entries...

JT
 

There does seem to be a bit of inconsistency, duplication and ambiguity in the ini files used and/or generated by either GUIs or configuration tools - is there available guidance on how to use the in file (or is that something I could try to contribute?).

I am planning to create a separate [MANUALMATIC] section where its ini options take priority over values set elsewhere - perhaps the GUIs should each use their own section and keep [DISPLAY] for purely generic/official display options?

The moving of (say) spindle options to a spindle section makes sense initially but should it also include purely UI options like INCREMENT? I don't really have a view on that, but it depends on what the ini sections are supposed to define. eg. TRAJ has options that apply to both the machine and the UI (eg MAX_LINEAR_VELOCITY) but others that it could be argued only apply to the UI (eg DEFAULT_LINEAR_VELOCITY).

I'm not really qualified to have an opinion on any of the above, hence the question, but would be happy to try to document the views of those who are qualified!

 

Softlimit values are accessible in the ini.* hal pins after startup has completed.
If changed during gcode execution (eg by using a custom mcode) they need a queuebuster command to be updated internally.
Limit switches can be disconnected/reconnected in hal.

1. Open the 'show halconfiguration' tool and check if the 'cia402_homecomp' component and its pins have been created.

2. Start linuxcnc from a terminal, select your config and check for errors: