Advanced Search

Lpkkk wrote:

ini and hal attached.
 

I see. No PID, although not mandatory mind you. Good move on uploading your set-up. Standby, I'm sure someone with extensive knowledge will swing in and sort that step/timing discrepancy. 

first ever trying to post something
after 12-13 times during my payed hours trying to install this i took home the shitty chinese computer and tried another 6-7 times... doesn't work
something it broken in the install 
 

Thanks a lot, I will try

I think it should definitely be deleted.

My setup:

• 3x nema23 ( no encoders) 3200 steps (i've also tried 1600 and 800, no difference)
• tb6600 drivers
• nvem
  
  ini and hal attached.
  
  I've tried to add deadband but no change. Please skip y and z axis for now, as most of my tests i'm doing on X axis so far.
  When i home my machine j0pos-cmd and j0pos-fb are the same, i've checked that again. When i go to x50 it stops at 4.995 and then if i go to x0 it will stop at 0.005

meister wrote:

new toy
works like a rotary-encoder, i think it should work in RIO

Haha that's so cool. Their output are indeed identical to those 90deg ABZ rotary encoder. Plugs right in your quadencoderz plugin and so no extra work required!

In the other RIO gossips; a brand new journey is about to begin!! However and before I begin routing this I wanted to poke your expertise and ask what would define a half-perfect RIO Motion Control Board. Is there anything fancy that we need on that other than the usual SPINDLE + MPG + XYZAB + Ins & Outs? 

yes it was in the RS274 values. didn't think about checking them.

Many thanks

thank you PCW !

the Linear Scale works with quadencoder(z) plugin

but the part from my link is really cheap,
ok for playing around, but to use it properly, hmm, no

I'm having a real hard time to get the linuxcnc-ethercat to run on our system... first i tried the one from rodw " build from repositories" but after 12-13 times getting stuck halfway the install i gave up and took the install from source path that corbett suggested... I have to rebuild to systems to ethercat, so i had one chinese made computer that i took at home and i installed everything and i choose to make deb... i can use these deb packages to install the same on the intel nuc piece of shite computer.... i'm alreday on this project for the last month and i am getting very frustrated ... i have to get these two systems to work ... i have two dinosaur plasma tables to rebuild ... took me forever to get my boss convinced to go the linuxcnc way and go the etchercat way ... got 2 systems with everything wired up for rtelligent stuff and i kinda need to get stuff working soon

.hal:99: Signal name 'plasmac.current-velocity' must not be the same as a pin.  Did you omit the signal name?
7168
7178
Stopping realtime threads

complete hal file attached

 

Hi rodw,
Thanks for your reply. I dug into CiA 402 to familiarise myself with it. I also contacted a Moons' representative who pointed me in the direction of the ESI .XML file for this drive. I then looked into the process suggested here: github.com/linuxcnc-ethercat/linuxcnc-ethercat for using these files to enable LinuxCNC using the generic driver to control an arbitrary driver.
Quoting: "The second way to use EtherCAT hardware is with the "generic" driver. You can tell LinuxCNC-Ethercat about your hardware entirely in XML..."
If I understand your suggestion of using the "CiA 402 driver" would be different to the above. 
Would you know what I could expect from choosing one path over the other in terms of complexity/chance of success?

In addition, am I right in thinking that compatibility with CiA 402 doesn't necessarily mean that every function / parameter described by the standard is supported by this particular implementation?. In other words, it would take some time effort to go over the documentation (assuming it's good and available) to find out how well they adhere to the standard... 

Many thanks, regards.
 

I've done the same thing more than once

centroidcncforum.com/viewtopic.php?f=57&...1&hilit=fanuc#p88931

Wow, this is a neat implementation! Fairly simple and seems to work well. Gets me thinking about my solution. Going to take some cramming to fit it all in the space I have around the spindle but it just might work. 

Some photos of the Hardinge Conquest spindle for those interested. This machine has an epoxy/granite base that you can see a little chunk broken off of in one of the photos. There is a gear-looking ring on the spindle that two separate pins can engage with (odd/even labels in documentation, maybe that stands for odd/even degrees based on their offset). Makes me think that a retractable worm drive could be fitted there in place of this system but that definitely seems more mechanically involved as it would have to be all custom. I wonder how Hardinge did their Conquests with full C axis..

 

 

 

It's hard to find anything clear on Fanuc stuff, but I think the spindle amp uses serial communication to/from the Fanuc control.  So while it may be possible...

Yes, very tricky to track down the Fanuc docs, mainly seems to be that they put a huge number of products in a single doc. I managed to track down the spindle amp documentation if anyone wants to see that. 400 pages or so, the forum wouldn't upload it so get in touch if you want me to send it over. 
 

It's a bit hard to tell because you don't have the line(s)
that caused the error in your hal file example.

We use 26LS32's a lot for a couple of reasons:

1. Their inputs are protected from up to +-25V
(the more expensive CMOS parts are typically protected to only +-14V or so)

2. Because they are TTL parts the outputs don't swing to 5V and if you add a 1K
pulldown, the outputs are OK for interfacing with most 3.3V chips.

3. They are much cheaper than  the CMOS equivalents.

The main disadvantage is higher power consumption