Advanced Search

I’m not a programmer (only a bit of Python, and some BASIC and C). It took me the whole day to find this issue, moving a debug print line around the code to locate where it was getting stuck.Thank you for the explanations, and also for pointing out the second copy/paste bug, I’ve fixed that one on my side as well.

Now I need to follow up with Pronest, as the post-processor still doesn’t insert commas between the parameters...

Regards

Well, we now know what I did to set the VFD into "coast down" mode. I pinned the drive enable to spindle on, and just disabled the drive to stop it. Doh! No wonder I didn't document it. 

Now I know that, I have a few options.
1/ Use ladder to react to a spindle stop command with an S0, wait a second, and then disable the drive. I had the VFD set for min 20 hz, max 70 Hz, so this would only brake down to 20, and coast down from there. It has the advantage that the spindle is not sitting on an enabled drive with an analog input, which could cause rotation from EMI induced voltage.

2/ Add a 24VDC output, wire that to Pin E3, and command the VFD to brake to a stop. I would probably still add a delay and disable the drive after a couple seconds. That would seem to be the proper way.

3/ But if I am adding another relay to to get me an extra 24VDC out, I may as well add more. Then I can also wire up the electro-mechanical brake, and have both VFD braking and mechanical braking commanded. This would also give me an option to add some ladder logic to use the mechanical brake on an E-stop.

Ideally, I would add the extra outputs with a second 7i84, as I maxed out the current one due to needing one I/O bank on 5V (for the Hall sensors for homing and tool change). I ended up scavenging a few extra outputs by using the unused axis enables on the 7i85, still ran out of 24V outputs, and put in a cheap relay board to use the excess 5V outputs to control 24V loads. I have an 8 relay card floating around, and could bodge that in instead of the 4 relay card to try this all out.

I will make a video to feedback what I actually do.
Cheers,
Mark

wenn du 2 MDI befehle hast, einer für 'an' und einer für 'aus',
dann kannst du zuerst ein 'toggle' machen und dann mit 'edge'
das jeweilige mdi triggern, je nachdem ob an oder aus.

im prinzip müsste es auch einfach mit der 'not' komponente funktionieren,
als mdi 'an' an das toggle und 'aus' über 'not'

Gruß,
Olli

Thanks for the sugestion. As I now dsided to go full Linuxcnc i will not use the system as is wary mutch. But i will seranly keep it running for now to find some stuff about it out.

Today, I’ve got my setup running with 3× Delta ASDA-B3 servos, a BK1100, and several EL1xxx DI / EL2xxx DO terminals.
I’m using the already implemented DeASDA driver (not CiA402), and the servos run fine.

My homing procedure uses HOME_USE_INDEX = TRUE. Everything works as expected: once the servo hits the index pulse, the homing routine completes and the position resets to zero.

I should mention that I’m fairly new to LinuxCNC, and this is also my first time working with EtherCAT, so I might be missing something obvious in the configuration.

There’s only one thing I still struggle with:
I’m getting a relatively large following error when I jog the servos using the keypad on the drive. Because of that, I had to increase the following-error boundaries significantly. (See INI-File)

At the moment, I don’t have any mechanics attached — the servos are running completely without load. I also auto-tuned the drives, so in theory the gains should be appropriate. What I don’t understand is whether this behaviour is caused by the EtherCAT cycle time (2 kHz) or by suboptimal tuning parameters (gains, filters, etc.) inside the servo drive despite the auto-tuning.

Does the following-error configuration need to be set differently when using EtherCAT communication compared to pulse/analog control?

I’m also not sure which exact HAL pins I need to connect to the Probe_Basic UI to make everything safe and fully functional. Any guidance on the required pins, signals, and safety interlocks would be extremely helpful for someone who’s still new to LinuxCNC.
I’d also love to see some example HAL/INI configurations of fully set up 3-axis machines, ideally with a carousel-type tool changer and a 3D probe — that’s what I want to configure next 

Thankfully I have a nice bench power supply from my bench flashing for ECUs / binary reversing, so stable power from 5-24v DC isn't an issue

Mark,

My spindle drive enable pin is tied to a 'machine-is-on' signal, and not to the M3/M4/M5 0-10v signal.  The drive isn't disabled at M5.

Check your HAL file (and watch the VFD enable pin in halshow) to see if you've got something connected funny.

Blech.

Windows 11.

Make sure you uninstall OneDrive as it slows down everything even if you don't use it or enable it for some reason (don't ask me why).

I will go read some more about G52, thanks!

No its Mach 3. The seller of the Mashin did not include the hard drive so i had to install windows and Win11 was just wat i downloaded.

Ewww...
Windows 11!

Is that Mach 4?

I wanted to be sure ... HAL_BIT will always return 'TRUE' or 'FALSE':

getp evokes the function do_getp_cmd, and inside it calls data_value2 to format the response:

github.com/LinuxCNC/linuxcnc/blob/73337a...cmd_commands.cc#L883

here is where HAL_BIT goes to 'TRUE' or 'FALSE':

github.com/LinuxCNC/linuxcnc/blob/73337a...md_commands.cc#L2473

So checking for '0' is probably unnecessary, but it doesn't hurt either.  

Really don't see what could be different between configurations that affect basic communications.

unless there is some marginal power issue (does the 7I96S reset when starting the 5 axis configuration?)
Or maybe a memory fault of some kind in the PC, the reported error really has nothing to do with the number
of axis.

And as I said, your 5 axis hal/ini files work fine here with a 7I96S

A pncconf created configuration might be worth a try, just to see if a quite different
5 axis configuration changes the symptoms.

 

Thank you for the help, I had narrowed it down to the rewrite_material_file method before I left for Thanksgiving dinner.  You definitely saved me time getting the rest of the way there.  From what I can tell without doing a bunch of digging, getp will return 'TRUE' or 'FALSE' when the halpin is setup as a 'bit'.  

I pushed your fix for this to the master branch:  github.com/LinuxCNC/linuxcnc/commit/7333...d08fd2855851c8ee91b3

I also found a copy/paste bug and fixed that as well.

Thank you again!

I’ll post my wiring diagrams once I’ve got them more organized, I’m working out of a google sheet that’s set up for tracking the status and purpose of each wire.