Advanced Search

Hi nwe,

That would be extremely helpful, thank you for offering to test.

No rush at all if it takes a couple of days — I will actually be working in the field for the next two days doing maintenance for a client. When I get back, I plan to implement the safety gate component and the decouple/recouple logic, so the timing works out well.

To prepare proper adapter templates for your two drives (the Lichuan OL57E-4A and the Stepperonline A6-750EC), I just need a few details from your setup so I can map the HAL pins correctly.

If possible, could you share:
1. Your LCEC configuration
• lcec.conf (or equivalent configuration file)
• The EtherCAT XML/ENI if you have it
• Or a snippet of the HAL where the lcec.* pins for the drives appear
2. PDO mapping
I mainly need to confirm the HAL pins for the standard CiA402 objects:
• 6040 Controlword
• 6041 Statusword
• 6060 Modes of Operation (command)
• 6061 Modes of Operation Display
If available in PDO as well:
• 6064 Position Actual Value
• 607A Target Position
3. Homing
• Which homing method (object 6098) you plan to use
• Whether the homing/limit switches are connected to the drive inputs
• The HAL pin names for those inputs (for example lcec.*.din-*)
4. Quick Stop
• Is Quick Stop (Controlword 0x0002) configured and usable on these drives?
• Or do they require a different shutdown sequence?
5. Anything unusual
• Any known quirks with enable, fault reset, or homing behavior.

With that information I can prepare two adapter templates (one for each drive) that plug into the CiA402 semantic layer we validated in simulation.

Thanks again for offering to test — having real hardware feedback will be extremely valuable.

thats pretty negligible to what i have. mine is far far worse. will share as soon as i get to my shop.

This issue originated from LinuxCNC and occurred nine times within ~30 minutes.

not sooo bad

not knowing how you print your message but how much of your main loop taken up by printing your message? It might not be as bad as you think.
Maybe an exercise for halstreamer?

Ja der alte Motor ist bereits Entsorgt. Ich war Überrascht über seine Leichtgängigkeit und seinem geringen Gewicht. Für das Alter. Hab ich mir anders vorgestellt. Ja der neue Servo hat selbstverständlich einen Encoder. Ich werde mal sehen was das Umkehrspiel sagt. Aber Früher hat es ja auch funktioniert. Wieso jetzt nicht mehr? Für gröbere Arbeiten sollte es nach wie vor reichen.

The" bitslice" hal component is one way.

 

Is there a way to extract a specific bit from a hexadecimal value? The VFD I'm using indicates the state with a 16-bit hexadecimal value, and therefore I need to extract that bit to use it within my configuration.

So we have wound up with a simple little 3 axis cartesian robot. Robot basically has a spindle taper and air powered gripper, and then hands off to a switcher arm that will be moved by the little robot with a roller cam. 





I will probably build this in april, then we can see if it can live inside the master linuxcnc or needs a separate controller.

So the run down:

- X, Y, Z linear motion.
- gripper air cylinder.

1: Robot on its own goes to grab the next tool needed by the machine, and places it in the arm SLOT A
2: M6 Tx called
3: Robot uses cam to move arm out into position. Door opens on the same linkage (we could also do this with air)
4: Machine moves to tool change arm and places the tool in SLOT B
5: Then it grabs the tool in SLOT A and moves away from the arm

Basically the main control sees the atc as a stationary rack type with only 2 tools

6: The arm retracts in and door closes
7: Machine resumes cutting
8: The robot takes the tool from SLOT B and puts it back in the right pocket
9: Robot grabs the next tool in the program and we repeat everything again

Make sense?

The new version of qtdragon at github.com/persei802/QtDragon_hd has the ability to semi-automate tool measurements. I'm open to suggestions for improvements.
Jim

setp [HMOT](CARD0).stepgen.00.control-type 0

Is wrong, it should be:

setp [HMOT](CARD0).stepgen.00.control-type 1

(for all joints)

 

clem wrote:

The are not Inovance, they are Jssmotors, as you can see in this link:

www.jssmotor.com/servo-system

You are absolutely right.  Earlier post edited - thanks.

Its about 0.17mm along the whole Z axis. Mostly near the chuck as always. Could you perhaps share a bit of what you had done? Attaching the picture of my bed wear. 

Pretty sure that if  you have combined home/limit switches you will need a
HOME setting that's away from the switch actuation point or the ON LIMIT
errors are guaranteed.
 

OK, so the only solution seems to be the timedelay/oneshot version, where it would command the tool change always in the same direction (not sure if ABS component helps), does need a bit of hal wizardry, but i am out of ideas for now on how exactly to achieve that.

From a very quick and short glance, what is this
setp axis.x.jog-accel-fraction 0.3
doing inside the hal file?
Probably not the exact issue, as i still think there is something terribly wrong with the wiring, but the symptoms are not that clear cut to be able to pinpoint.
Check with scope how the signal between signal pins on Mesa and drive look in relation to gnd and machine/box ground look, might be ground interference at 50 or 60Hz causing it.