Advanced Search

Thanks rodw, I had ordered a DM542 from Steppersonline and it arrived today. Even with the 24v and 270OZ stepper and DM542 set at 3A I now have plenty of torque. Problem solved. I guess the TB6600s weren't up to the task.

satiowadahc wrote:

slightly off topic but related, A fun addition I made to our Gui.

Added a button that when you pause a program it appears. Saves the current position, current spindle speed, does a safe z move, switches to manual mode so you can jog.

 

satiowadahc hasn't been on the forum in a couple of years.  Anyone know what UI they were talking about?

I'd love to have exactly that feature.  The other day I was pretty sure my vacuum had clogged, since the pockets I was carving were completely full of sawdust about 3/4 of the way through the job.  If I could have, I'd have paused, done some hand vacuuming, and then kept going.  Other times I've thought, "sure wish I could recheck the positioning of that clamp", sometime after the job has started.

OUCH! 25KW DC motor... you win! I have a 11KW one on a Mazak lathe.
If the drive is working, i would not change it, well i did not change mine, so
-K332 is relay contact for enabling the drive
-Sollwert should be the analog +-10V input
There are other things there, but for now if the rest of the installation is OK, that should be it.
You would need an analog Mesa card like 7i97T or 7i92TM with 7i77, or some other combination.
In general, i use the old drives and motors whenever possible.

I would try to use them for sure, they are very good quality drives and new cost an arm and a leg, so try finding some used motors that work with these drives, for a reasonable price if possible.
Mind the encoder type.

That's a good suggestion. I comment out the offending lines and looked around "Show HAL Configuration"

Turns out, probe.* pins don't exist. HOWEVER, gladevcp.* has all the pins that have been implicated, including gladevcp.toolchange-change and gladevcp.ps_probe_max

The Z-height probing routine kicks off a message complaining that probe.ps_probe_max is not available so I thought I'd try to name it at the outset. I tried using EBMED_TAB_COMMAND to adjust the component name with -c probe but that doesn't run.
I dug around some more and found a line in probe_screen.py that was commented out.I un-commented it and it may have this particular problem. Makes me nervous because there are other lines nearby that are commented out...

Thanks for the tip, Aciera. Great handle, too.

Ah-ha! The 24V field power GND is not connected to earth ground, I was not sure that it should be. That probably explains it then.

Just weird that the machine ran fine for so long.

Thanks, I was getting frustrated with the constantly changing symptoms. I will connect those grounds tomorrow and test again.

The hal driver installation is easy, you need to open terminal navigate to the hal-driver directory and run ./install.sh

Sample hal configuration in the hal-driver/test_config directory

Precompiled .uf2 in the repository binary directory, you not need to rebuild the project if you want to use

Ack!! 40V is a real issue and indicates a grounding problem. This likely
what damaged the step/dir outputs (accidental contact to shield ground would do it)

I would verify that the drive frame grounds connect to earth ground and that the
7I76E ground (24V logic power ground) is also connected to earth ground.

well now all 3 drives are in op mode with no errors showing.

... now what do i do? haha

Yeah that didn't work. I found a different xml with more "stuff" (pdo, etc) and it has put me in OP mode. even though I don't see any actual difference.

But its progress!

Hey, you can try this one out, its still got some buts but it does the thing you want
github.com/cakeslob/regularmac_800/tree/search_gcode

From that Omron thread, it looks like Arvidb got it working, so can you try with the ecat-conf.xml?It's the same xml that Arvidb used, but I have changed to what I think it the right model, based on the product code 6 you use.

You need to remove this from your hal


You are already loading probe_screen.py with the EMBED_TAB_COMMAND in the INI.

To troubleshoot the pin problem, comment all lines with 'probe.' pins so the config starts up and use the 'Show Hal Configuration' tool to check if the pins are there.

Sooo, back at my ethercat fun and I think I've made progress, but I'm stuck.

I've gone right to the basics and am just using halshow to poke the drives.
I made a super basic xml file following some other examples on here.

So, following this:
EtherCAT: How to use the dedicated OmrG5 lcec driver? - LinuxCNC $ ethercat slaves shows me my 3 drives just fine
$ ethercat upload -p 0 -t int32 0x6064 0x0 shows me position just fine
$ ethercat safeop doesn't work and returns error 90 because the default sync0Cycle is wrong. This seems expected.

My xml is:

<masters>
<master idx="0" appTimePeriod="1000000" refClockSyncCycles="1">
<slave idx="0" type="generic" vid="#00000083" pid="#00000006">
<dcConf assignActivate="300" sync0Cycle="*1" sync0Shift="0"/>
<watchdog divider="2498" intervals="1000"/>
</slave>
</master>
</masters>(using the generic driver here cause the omron one was saying no drive found)


then we do this in halshow:
loadrt threads name1=master period1=1000000
loadusr -W lcec_conf linuxcnc/configs/ecat-test.xml
loadrt lcec
addf lcec.read-all master
addf lcec.write-all master
start

All works, except after we get to start, the drives show error 83, and if you look at the pins, its actually cycling through preop, safeop, inti, op, error every so many ms.

So what have I done wrong here, or what do I need to add? The are many gaps in the information and steps people provide so I expect there's just something missing I don't know about.

Thanks!