Advanced Search

I looked at your long list again. My opinion is a.i. bots frequently over engineer a lot of insignificant points.

I might be able to help some, if I can find the time. I can't provide a comprehensive package like your list asks for, but here is a start.

For the limit switches I suggest Automation Direct part number AAM2F43Z11, I like to set them up in a drive-by configuration, where if the axis over-runs its hard stops a bit you're not crushing the switch. If any of these will be used as homing switches you should replace their snap action contact blocks with the teasable version: Automation Direct part number AGX11-SWITCH, I used that in a project a while back and it worked great.

You probably need 6 limit switches for the X and Y axis total. How about the Z axis? What does that one look like? I might suggest just one upper limit switch for that. The bottom limit is going to vary depending on your table height and workpiece thickness. Does your torch holder have a collision sensor to detect when it runs into a protruding edge, like when a smaller piece tips sideways?

For the cords from limit switch to control cabinet I would suggest something like:

Automation Direct part number CC600-16-3S-1 You don't want to use this for circuits that need to flex all the time. I would use this wherever it can be strapped to the frame, etc.

For any limit switch cords that have any flex points or travel through a flexing cable tray I would use something like Automation Direct part number A3131603-1

Both cords are shielded. I would probably use only the second one on the entire project. In applications like this, I like to route the low voltage signal wires through a separate conduit, not the same one as your h.f. power cables. If strapping to the frame, bundle them separate and keep the two bundles separated by several inches, and don't cross them directly over each other. Ground the shields only at the computer end and isolate them at the switch end.

You don't have to get everything from Automation Direct. It is a supplier I use a lot, so I will end up referring to them frequently.

Drawing wiring diagrams is fun. Mostly I sketch them up using paper and pen. Maybe sometime I'll find time to learn how to do it in Qelectrotech.

That's where I tried putting it but it didn't seem to work. I might have the format of the entry wrong, I'll play around with it again
Thanks

Thanks that clears up most of it. On the 1.4 board there's pin p1.31. What would that connect to on the w5500 board? In the video there's a power supply going to the w5500 board. Does it need 5v, 3.3v, or both? The documentation shows that it's possible to power a raspberry pi with the 1.4 board. Is it possible to do the same with the w5500 board? Looks like there's 5v there.

   

A VFD is normally not a very good servo system because it has such limited control bandwidth.
It may be workable if orientation is run very slowly, you have a good spindle encoder and do not expect
perfection in the orient angle.

Sim works here but i am on 2.10/Master version.

That's what I expected, its the output scale.
(analog scale for analog out, stepgen scale for step/dir out)

Ich denke da kan nur eine won diese karte an die 7i97T werschteckt werden, fur die andere da muss noh ein 7i74 sein und das gibt noch 8 SSerial kanale.
Shau mal wiviel ein 7i92TM mit 7i77 kostet, brauht nicht die 7i84 mehr und can die 7i73 an die 7i77 werdahten. Das ist nur 32 eingange und 16 ausgange.

Hello,
I am retrofitting a lathe and replacing the original 30kw Baumuller servo spindle with a 7.5kw three phase motor. The main reason is the controller is dead and repair is not worth it for me money wise. The lathe has a C axis with hydraulic disc brake. I do not need an active C axis, just orienting and locking in place is enough for me. Would this be possible to achieve accurately with the VFD? If so, have anyone perhaps tried it and could give reccomendations for the VFD and motor parameters? How many poles, etc. I need max 6000RPM from the motor, the spindle has a 1:2 belt reduction. 

Does not seem to be my brake logic. Now I have it searching for home slowly for several inches. It touches home then my pid.output slams in reverse, pulling back off the home switch then I get this error:
Home switch inactive before start of backoff move j=6

Ah-ha! This must be something with pid tuning. I suspect my I-gain is too low. And maybe I need to give it some D-gain.

My brake logic is (if I'm correct) straight passthrough during joint motion. The only exception is the enabling period at start of motion (currently 0.05s) and the parking after 10s of no axis motion.

edit: More than anything else, looks like MAX_ACCELERATION was way too high.
Another problem was the homing is not finding the encoder index, disabled the home-to-index for now.

Now I got joint 6 homing. Needed to make some polarity corrections to HOME_SEARCH_VELOCITY and HOME_LATCH_VELOCITY. Next problem: I command it to go to R 0.000 and it goes to R -0.7683 instead, showing -0.7683 on the gui and that is also where it seems to be at when I measure the physical joint position. This is the motor offset value that is being set during homing. Looks like I need to sort out in my config which value is "raw axis position" and which is the "user friendly value"

This did it: I adjusted HOME_OFFSET so I could command 0.000 and have it go to 0.000
To correct the joint position readout in the gui I moved its hal pin from hm2_7i80.0.encoder.00.position to joint.6.pos-fb

For a bit I made poor progress tuning the R axis. No wonder, it has a brake in the servo and I overlooked that. Yesterday I had a bad day with that little brake. I was manually driving that axis closed loop by setting j6.pid.command and j6-unlock via halcmd in a terminal. I parked it with the brake locked, jiggled pid.command around till pid.output went to 0.0000 then looked at my brake hal logic....

About 2 hours later I was submerged in hal logic. 30 feet away a guy was welding. Somewhere in the back of my mind I'm blaming him for welding through paint. 5 minutes later the boss comes worrying. "I smell hot wires!" He stuck his nose in the big cabinet... nothing there. He walks around the back of the press. Phew! I hit e-stop, cutting power to the servos, but that nice old Baldor DC servomotor is now junk. Good thing I earlier forbade the boss from promptly scrapping the PSA and PSB axis. It had an identical motor.
It appears the brake had at some point allowed the axis to drift down about 7 encoder counts. At that point the pid slowly wound up but the motor was unable to fight the brake back to 0.000 position and gradually overheated and then smoked.

I now have hal logic automatically operating the brake for me. But it is interfering with the homing. I just now saw into it: my servo enable after brake release delay must be slightly too long. Homing starts then after my 0.1s delay the pid has some catch-up to do and overshoots just enough to fault the homing sequence.

I'm attaching my complete config. Most of the working part of it at this point is joint 6 (almost working). More to come...

In the ini file for a test I just did I see the following
JOINT_0
SCALE = 1000
ENCODER_SCALE = 10000

In the main.hal file
setp hm2_[MESA](BOARD).0.pwmgen.00.scale [JOINT_0]SCALE
setp hm2_[MESA](BOARD).0.encoder.00.scale [JOINT_0](ENCODER_SCALE)

JT

pncconf does not know about the field output options of the 7I76EU
(it only knows about the 7I76E)

The 7I76EU  has individually settable output modes for each output.

The default setting is sourcing mode on all outputs.

Sourcing mode means the 7I76EU outputs supply positive field voltage to a ground referred load
This is identical to the original 7I76E.

To set up sinking or push-pull outputs you must set the source or sink
parameters. These parameters are 16 bit numbers where each bit determines
the output mode of a single output. Bit 0 in the source and sink parameters
control the operation of output 0 and so on.

The default setting is source = 0xFFFF and sink = 0x0000 meaning all outputs are set to
sourcing mode.

To set to sinking mode, you set the desired sink bit to 1 and the corresponding source bit to 0
 To set push-pull mode, you set both the sink and source bits for the corresponding output.

That is if you wanted the first 8 outputs (0..7)  to be sourcing and the last 8 outputs (8..15) to be sinking
you would set the source parameter to 0x00FF and the sink parameter to 0xFF00

This is described on page 17 of the 7I76EU manual

Note the these parameters cannot be set dynamically, they must be set with setp commands in the hal file.

 

Die Eingänge laufen bei mir wie gewünscht, leider bekomme ich die Ausgänge nicht in Betrieb. Ich möchte gegen Gnd schalten, passieren tut nichts

Nachtrag: Verdrahte ich Output 0 auf TP6 als Schalter gegen + 24V (d.h. die Last liegt auf der anderen Seite an Masse) dann funktioniert es. Ich dachte die 7i76EU hat Universal Outputs, d.h. kann beide Modis?

Fastfred wrote:

I did try reversing the input, Does my custom.hal file look correct? I get a joint 0 amplifier fault instantly its the only joint i am trying to figure out at the moment i haven't tried to add the other joints yet. Is there other ways of doing this that might be easier to add in my case ?

Thanks

First thing to do is make sure the Clearpath's HLFB function is programmed the way you want/need.  Teknics permits a multitude of conditions which result in <some> sort of signal from HLFB, but I suggest you copy @djdelorie's setup and program the HLFB pin to be HIGH when 'enabled and following.'

Next, test the HLFB programming and your wiring to make sure LCNC is getting the HLFB signal properly.  With any amp-fault stuff commented out of HAL, start the machine.  The Clearpath should be enabled, and you should see (in halshow) the input pin which is connected to the HLFB output go HIGH (conducting).

You can also take this opportunity to estimate how long it takes the Clearpath to switch the HLFB signal from LOW to HIGH when it is enabled.  You will want this delay estimate later when configuring the amp-fault time-delay in HAL.

Once you've satisfied yourself that you have everything outside LCNC sorted, you've got a decision to make regarding the other servos' HLFB signal.

- If you want LCNC to 'know' which specific axis/motor trips, you will be using up an input pin for each motor's HLFB output signal.  You will also need a HAL configuration the same as (or similar to) @djdelorie.

- If you don't care which motors trips and just want the machine to stop when any motor trips, then you can wire the HLFB signal from all motors in a series and have a single 'amp-fault' input to LCNC.  This will reduce the number of inputs used to one, and will make the HAL configuration somewhat simpler at the expense of slightly more fussy physical wiring.

Do the tests (and HLFB programming), and think about the 'decision' I mentioned and come back here... we'll help you sort out HAL so everything works like you'd prefer.