Advanced Search

Drive needs to be in torque mode, not velocity.

My experience is that it's better to have PI from the load-mounted encoder.

Dual-loop has always been my standard. Motor shaft angle is unimportant, we care about where the load is. Within reason, backlash becomes a non-issue.

Hi Scott,

The motors do have 2000CPR encoders on them, but they do not tie in with the "dumb" servo amps.

The ballscrews/nuts (or maybe thrust bearings) have some wear and there is more backlash in both X and Y than I'd like to see. When/if I start spending any money to improve things on this machine, that's where it should go first. Maybe I'll luck out and the nuts can be refitted with the next size larger balls and it won't break the bank. I didn't pay that much for the machine, and it's primarily for hobby use, so I don't want it to become a money pit.

Until that time, it doesn't cost anything except my time to play around and see if I can get dual loop working. It's a good learning exercise if nothing else.

Hello

the qtplasmac interface can be used with 2 spindles (plasma, scribe)
but although scribe doesn’t require a probing sequence, just commanding the plasma “m3” command will initiate a probe sequence and will require a z axis.

i have a need for a double head system without Z axis, where a probe is not present. One of the tools can be linked to the scribe, so it won’t require probing, but the other I need to link to plasma; and remove the probing sequence somehow.

how is this doable? Can I change the m3 macro in its source files? How are they accessible for a simple install?

I know I can use other interfaces such as gmocappy but qtplasmac has conversational and statistics which is great.


edit: 1 approach would be to actually keep the probe and use the negative direction pin on Z axis to drive a timer which drives the ohmic sense signal. But this feels weird.

Did you try the I/O health check?

The cable looks correct,  maybe make another cable as either end may be flakey

(you can verify with connector location with mesaflash --device ethernet --addr 192.168.1.121 --readhmid --dbname2 7i52)

 

Hello again.
No luck so far with the setup I need.
I have tested some things on another system with some positives:
Connecting my 7i84 through a 7i94 and using the command:

sudo mesaflash --addr=192.168.1.121 --device=ETHER --sserial

gives me a response from both of my 7i84 cards - they are detected here, showing SwRevision = 14, baud 2.5Mb, NVUnitNumbers etc. So my 7i84s appear to be OK.

I can start up a simple lcnc config using the 7i94, with one pin in use from the 7i84, with no errors.

I can use:

sudo mesaflash --addr=192.168.1.121 --device=ETHER --readhmid

on the 7i80HD, loaded with the firmware you gave me, and get the pinout I'm expecting with SSerial TXData0 on I/OPort 45, SSerial RXData0 on I/OPort 46, and SSerial TXEn0 on I/OPort 47.

However sudo mesaflash --addr=192.168.1.121 --device=ETHER --sserial gives me no response here - not even an enumeration of the SSerial ports shown on the readhmid list. Earlier yesterday the mesaflash...--sserial command used on the 5i23 was giving me a few lines as a response, but seems to have stopped doing that.


What I can't seem to do anymore, is use a 50-pin flat cable to connect a 7i52 to an fpga card, and connect to the smartserial card that way.

I've checked my cat5-to-terminal wiring a handful of times but still am not sure it's correct. It looks like this:

 
 

Also, can you confirm that that terminal block should be plugged into the bottom 8 pin space of P3 on the 7i52, which I think is COM 0?

The likely candidate really seems to be the cat5-to-terminal wiring, but I'm reasonably sure I haven't changed that since it worked!

Have also tried swapping out 50-pin cables, using cable and ext. 5V power for the 7i52, swapping out 7i52 for a spare, swapping out 7i84 for a spare, and as many combinations of these as I can. Properly stumped. I would be grateful if you could confirm the cat5 cable wiring and the correct 7i52 terminal position. 

Setting the input filter to 0.1 usec did the trick. The sensor does output a square wave, but it's not very clean or stable. For some reason, I can't get the periodm frequency value to show any change in sensor output no matter how close or far I am from the sensor. With the sensor at a static range, there is a considerable amount of noise causing the sensor to range from 2.38 MHz to 2.42 MHz, with some blips above and below that even. For now I'm going to revert back to the flip/flop as that was working, although the sensor still has oddities at the extremes. Perhaps I need to buy a new BCL-Amp.

I am powering the sensor from the +5v from the encoder rail on the 7i76e. Is this power clean enough? Or should I add decoupling caps/use an external power supply?

 

Edit: I've added the current frequency response I get from the sensor once it's gone through a 74HC14 Schmitt Trigger and then a 74HC74 Flip Flop. The Z move is 0.500", and the peak BCL-Amp-freq is at about 0.060" above material. Perhaps I don't need the first Schmitt Trigger because the 74HC74 has a Schmitt Trigger as well. I'm having issues figuring out how to deal with the response after ~0.100" Z, it causes my "voltage" to go back up. I only care about the first 0.050" or so for THC purposes, but if the metal buckles or there is a drastic change in height, it will cause issues with the THC.

Note that I wasn't seeing this inversion when I plugged the signal straight into a non-muxed encoder without the flip flop. The signal started high and decreased to zero, my current frequency reading is starting low and increasing and then decreasing the further it gets away.

I assume you have a tach to close the velocity loop on the drive. The dovetail config on the Bridgeport should give you plenty of friction. Dual loop with scales should be very stable. Make sure the thrust bearings and ball screws are in good shape. The best cure for backlash problems is to fix the mechanical problems first, every thing else is to hide the real problem.

Good luck,
Scott

ok, thanks.

Hi,

Got an issue with the default "Go to sensor" button ignoring tool offsets (X and Y axis).
It is possible to customize the script behind the button, or is it all hard coded?

Edit: Running LinuxCNC 2.9.2 with QT Dragon HD and Probe Basic.

Hi Rod,
These 35 year old drives/amps don't have any way to close the loop internally. They're just offset PWM in -> +/- DC voltage out as far as I know. There's no microcontroller in them, and the motor encoders don't connect to them. The signals were passed directly to the primitive Prototrak Plus controller/DRO box.

cheers,
Steve

I thought the intention was to close the velocity loop on the drive/amp and to close the position loop from the scales in linuxcnc.
But I've not got any experience to add.

This video goes over all of the cut settings for Cypcut, which seems to be the main control software for fiber lasers.



One that stood out to me that would be beneficial to add in addition to the ones you've already mentioned is "Delay time" which allows gas pre-flow before the laser turns on. A lot of the other ones are already in Plasmac, which is nice.

Dynamic power adjustment based on speed would be nice, there's some good info already here: www.forum.linuxcnc.org/10-advanced-confi...-velocity-controlled

I have been thinking about trying to implement a capacitance calibration component. I switched from a 1.5D nozzle with O2 to a 1.2S nozzle for compressed air and my capacitance (voltage setting) was not working well. The numbers need to be tweaked and it would be helpful to have a somewhat automated tool to aid. I haven't tested how repeatable the sensor is, but it is possible that taking the nozzle on and off again could adjust the target capacitance tracking value. I haven't drained the water yet from my plasma table, and that is definitely affecting the readings.

What NIC are you using for ethercat? Is the MAC address set correctly in this file?
Check the MAC Address with ip a
Your file mentions enp3s0 but thats not what you are using based on dmesg

If you are using ISE >13.1 it only matters if encryption is used (its not)
I actually don't think it matters even on ISE < 13.2 as it seem more related
to Xilinx's core generator (which the source does not use for portability reasons)

One thing I'm questioning is whether both the inner and outer PIDs should receive the same position command signal. It isn't really shown explicitly in the simplified Galil drawing, though the wiki example definitely does it this way.

Also, I want to make sure I understand the nomenclature. I think I wrongfully assumed this type of dual loop was a velocity loop (inner) and position loop (outer), but the outputs from both loops are velocities, so I think that's wrong. You can see my confusion in the initial configs I posted as I called the PIDs "vx" and "px".

Next up, the Prototrak DC servo amps are PWM input -> motor output voltage. Varying the voltage on an unloaded DC motor varies its speed (velocity). These are just amps and not closed loop drives - the motor encoder output just comes straight into the Mesa card. I am a bit confused on whether this is called "velocity mode," however. Is that term reserved for a drive which itself runs a loop with the motor encoder to maintain the commanded velocity?

Which leads me to wondering whether the velocity outputs from the motor encoders should be used. Andy, you kind of hinted at that the other day. I'm curious how you would see that fitting into this diagram.

Thanks in advance.