Advanced Search

Thank you! Now it works! Does the init move and moves the machine. I even managed to get PID so that ferror is less than 0,03 mm up to 17 m/min. There is some noise/vibration but I think that is manageable issue

Thanks for that link, a lot to absorb...
M

Hello everyone,

First post here so forgive me if this is the wrong sub-forum to post.

I'm trying to build a simple 3D touch probe (the "6 balls/3 pins" kind). Probing seems to work but it's currently not very accurate (calculated pretravel variation of ~70um). I'm using LinuxCNC 2.9.2 with Mesa 7i92+7i76 on an i3-2100. Probe Basic as GUI.

While looking at my oscilloscope trace of the trigger signal, I was wondering how fast I should expect the movement to stop once motion.probe-input is triggered. Is it normal to expect a 5-10+ ms delay or there is something wrong with my setup? What I'm seeing is that even though the probe triggers immediately after a light touch to the object, the probe switch opens after some time (as if movement towards the target of G38.2 continues). Is this behavior normal?

Even if there is a significant delay, should I expect the value reported in #5061/#5062/etc. to be the exact position when motion.probe-input has been triggered?

Looking at the code (github.com/LinuxCNC/linuxcnc/blob/master...otion/control.c#L693) the position is saved immediately upon triggering and tpAbort is called (tp == trajectory planner?). Assuming that this code is called from the 25us thread, it seems strange to see the probe switch open after 10ms.

Attached is a capture from the oscilloscope. Channel 1 is the voltage at the probe (probe is the lower leg of a resistive divider) and Channel 2 is the trigger signal.

Thanks in advance.

 
Hi all,

After updating my system from 2.7 to 2.9 I am experiencing a lag when changing directions with my MPG wheel. It is like there is a short period of time (maybe 1/4 second) after changing direction (e.g. +X to -X) when linuxcnc is ignoring the MPG pulses. Otherwise, everything seems to be working fine as it did before the update. Does anyone know if 2.9 has any settings that might cause (or fix) this?

The HAL file is attached. I'm following up with the pendant manufacturer as well, but it looks like they just made changes for the joint/axis separation in 2.8.

updated version LinuxCNC 2.9.3  Debian 12 Bookworm PREEMPT-RT ISO  
Vista cnc M1 USB pendant 
Atom 525MW motherboard
Mesanet 5i25 PCI board--using its parallel port

Thanks,

Rob
 

Yeah, the watchdog they have in Syncthing seems to loop more often than every couple of minutes. I also almost just wrote a simple watch script in python to monitor the folder and pull any changes. Of course pushing is always more ressources economical. I just assumed the mechanism they implemented in Syncthing would be more efficient than any of my poor man's solutions.

Any idea where I can suggest to Probebasic to implement a REFRESH button?

Yes, it's set for 7.5 A full scale
I would set it for 30 A full scale

with

setp xxxx.xxxx.nvmaxcurrent 3000

in the hal file

(this will only take effect after a 8I20 low voltage power cycle)

(pretty sure this will work on a 8I20 Otherwise it will need setsserial)

What are the nameplate ratings of the motor? (voltage and peak amps)
 

You might want to look at this.
www.ametherm.com/inrush-current/transformer-inrush-current.html

-

I'm building a new power supply setup for use with a some feedback hybrid stepper motor. The driver for these motors can accept 24-80V AC so I'm just using a toroid transformer without the rectifier/cap

The transformer is a Hammond 1182S30:  625VA
Pri: 2x 117v
Sec: 2x 30v @10.42A

It will be wired with the primary in parallel for 120V 60Hz and the secondary in series for 60V at 10A

The toroid needs a slo-blow fuse because of the inrush but I'm finding all kinds of different information on calculating the fuse size. My first instinct is 625VA / 120V = 5A but when I'm looking around the net I'm seeing values down closer to 750mA or 1A being used. I know this is a larger than "normal" transformer but I just wanted to double check in case I'm missing something.

Also, I'm tapping off before the toroid to another 120 to 3.3/5/12vdc small transformer for the control system PLC, is that going to be an issue?

Any input would be greatly appreciated
Thanks
M
 

 
 
Hello folks.
In these days, i am trying to integrate joystick control to my system. My machine has 5 axises. (3 linear + 2 angular). Since the joystick control has limited controls, i wanna use it efficient. This is my method,

The right joystick will control Z axis in horizontal direction(I've already done it, you can check it on uploaded hal file.) But vertical direction will be different. I wanna be able to jog any axis except Z axis with this joystick. The joystick contains 4 buttons named X,Y,A,B and they are my axises. The thing i wanna do is, jogging the selected axis by horizontal direction(gonna be determined by whichever button pressed last). I've figured it out about homing axises in the same way, but jogging seemed different to me. I've tried to connect joystick signal to 'halui.jog.selected.increment' pin but it didn't work. 

Here is my questions:
1. Is there any way to do it without developing extra hal components? I can figure it out via a component which acts as an intermediate component, but i would appreciate any solution without develooping an extra component.

2. What does halui.jog.selected.increment pin actually do? Is it appropriate for my purpose, should i use it or check another way to do it?

I am uploading my hal file to attachments, thank you for your time.


My hal file looks like this:


loadusr -W hal_input -KRAL F710
loadrt joyhandle names=joyZ,joyY

# ...

loadrt oneshot names=estopTriggeredFromJoystick.oneshot,estopResetFromJoystick.oneshot

# ...

# JOYSTICK
addf joyZ servo-thread
addf joyY servo-thread

# ...

addf estopTriggeredFromJoystick.oneshot servo-thread
addf estopResetFromJoystick.oneshot servo-thread

# ...

# ...

# ...

# ...

# ...

# ...

# ...

setp halui.jog-deadband 0.0
setp halui.jog-speed 700

setp joyZ.power 3.0
setp joyY.power 3.0

setp joyZ.deadband 0.1
setp joyY.deadband 0.1

setp joyZ.scale 1.0
setp joyY.scale -1.0

# Connect joypad sticks to joyhandles
net velX input.0.abs-rx-position => joyZ.in
net velY input.0.abs-ry-position => joyY.in


# Z axis jog (gonna be strict)
net jog-z-analog <= joyZ.out => halui.jog.2.analog


# Other axises jog(gonna be dynamic, halui.jog.selected.increment could be used)
net jog-y-analog <= joyY.out => halui.jog.1.analog

net joyButtonX <= input.0.btn-x => halui.joint.0.select
net joyButtonY <= input.0.btn-y => halui.joint.1.select
net joyButtonA <= input.0.btn-a => halui.joint.3.select
net joyButtonB <= input.0.btn-b => halui.joint.4.select


# Home last selected axis
net joyHome <= input.0.btn-tl => halui.joint.selected.home 


# Set Estop on
net estopTriggeredFromJoystick <= input.0.btn-tr => estopTriggeredFromJoystick.oneshot.in
net estopTriggerJoystick <= estopTriggeredFromJoystick.oneshot.out => triggerEstopFromUserspace.or.in0

# Set estop off
net estopPulseJoystick <= input.0.abs-rz-is-pos => estopResetFromJoystick.oneshot.in
net estopResetJoystick <= estopResetFromJoystick.oneshot.out => halui.estop.reset


# ...
# ...

# Home all axises
net joystickHomeAll <= input.0.btn-thumbl => halui.home-all

 

Ethercat is a standard created by and registered to beckhoff. Codesys and Twincat are a blanket term for programming and runtime environments along with related technologies.

Ethercat does not use TCP nor can you have TCP on the bus.

This is the esi file, I haven't tried it yet but the OEM sent it over along with an older version.

<!-- AX58100 EVB ESI Sample File - "AX58100 EVB (Digital 16-Input/16-Output)" -->
<EtherCATInfo xmlns:xsi="www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="EtherCATInfo.xsd" Version="1.2">
<Vendor>
...
</Vendor>
<Descriptions>
<Groups>
<Group>
...
</Group>
</Groups>
<Devices>
<!-- DIO, GPIO, FMMU=2, SM=3, DI=16, DO=16, ProductCode="#x00010200" RevisionNo="#x00000001" -->
<Device Physics="YY">
<Type ProductCode="#x00010200" RevisionNo="#x00000001">AX58100_EVB_DIO_16</Type>
<Name LcId="1031">AX58100 EVB (Digital 16-Input/16-Output)</Name>
<GroupType>AX58100_EVB</GroupType>
<Fmmu>Outputs</Fmmu>
<Fmmu>Inputs</Fmmu>
<Sm StartAddress="#x0f02" ControlByte="#x44" Enable="1" OpOnly="1">Outputs</Sm>
<Sm StartAddress="#x0f03" ControlByte="#x44" Enable="1" OpOnly="1">Outputs</Sm>
<Sm StartAddress="#x1000" ControlByte="0" Enable="1">Inputs</Sm>
<RxPdo Fixed="1" Sm="0">
<Index>#x1a00</Index>
<Name>Byte 0</Name>
<Entry>
<Index>#x3101</Index>
<SubIndex>1</SubIndex>
<BitLen>8</BitLen>
<Name>Output</Name>
<DataType>BITARR8</DataType>
</Entry>
</RxPdo>
<RxPdo Fixed="1" Sm="1">
<Index>#x1a01</Index>
<Name>Byte 1</Name>
<Entry>
<Index>#x3101</Index>
<SubIndex>2</SubIndex>
<BitLen>8</BitLen>
<Name>Output</Name>
<DataType>BITARR8</DataType>
</Entry>
</RxPdo>
<TxPdo Fixed="1" Sm="2">
<Index>#x1600</Index>
<Name>Byte 0</Name>
<Entry>
<Index>#x3001</Index>
<SubIndex>1</SubIndex>
<BitLen>8</BitLen>
<Name>Input</Name>
<DataType>BITARR8</DataType>
</Entry>
</TxPdo>
<TxPdo Fixed="1" Sm="2">
<Index>#x1601</Index>
<Name>Byte 1</Name>
<Entry>
<Index>#x3001</Index>
<SubIndex>2</SubIndex>
<BitLen>8</BitLen>
<Name>Input</Name>
<DataType>BITARR8</DataType>
</Entry>
</TxPdo>
<Dc>
<OpMode>
<Name>DcOff</Name>
<Desc>DC unused</Desc>
<AssignActivate>#x0000</AssignActivate>
</OpMode>
<OpMode>
<Name>DcSync</Name>
<Desc>DC for synchronization</Desc>
<AssignActivate>#x0100</AssignActivate>
<CycleTimeSync0 Factor="1">0</CycleTimeSync0>
<ShiftTimeSync0>0</ShiftTimeSync0>
</OpMode>
</Dc>
<Eeprom>
<ByteSize>2048</ByteSize>
<ConfigData>040f0044102700ff000000000000</ConfigData>
</Eeprom>
</Device>
</Devices>
</Descriptions>
</EtherCATInfo>

Linux 2.9.3 and any D greater than 0 will cause a "G7X error: Cannot intersect parallel lines". With a D0 value it will function perfectly.
Any Gurus who have an idea what the problem is would be appreciated. Code attached.
Thanks 

Check also steplen, stepspace, dirhold and dirsetup values.
Some of those may be too short and then you lose steps

Hi JT,
Found the problem, I downloaded and installed the latest iso which according to the installer is 2.9.3 and apt-cache policy reported the above so I guess its not really 2.9.3
I then did sudo apt update and sudo apt upgrade and now apt-cache policy linuxcnc-uspace reports 2.9.3.

Or, it just occurred to me, i have used those cheap arduino BTS7690 or whatever the numbers are, to control a heated bed on a 3d printer, worked perfectly and stayed cool at 12A of current. Think of it as 2 of high side and 2 of low side FET's, and they can be controlled from low level Mesa pins so can use hardware PWM at high frequencies.
Also makes wiring much easier and are very cheap.