Advanced Search

 
 
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.

Have a read thru this thread.
forum.linuxcnc.org/9-installing-linuxcnc...4-and-raspberry-pi-5

Please find attached main INI and HAL files.
8I20 current scalemax and PID max output are set to 30, while 8i20 nvmaxcurrent is 750 (is that 7,5A?)
I tried increasing servo thread rate to 4 kHz but the pc could not handle that - I got immediate realtime errors. Now the servo thread rate is 2,5kHz with traj_period set to 3x longer than servo_period (that did improve picture in latency histogram).
Another change from previous attempts is reinstalled to Debian12 and LinuxCNC 2.9.3. What I have now is that bare motor moves fine, PID is tuned to a peak ferror of 0.2, but when I put the belt on, there is no motion at all. It cannot do even init move for bldc. I can easily move the motor by hand and that is how I get init-done. Then if I try to jog, there is no motion at all. pid output goes up until it reaches max, but nothing moves. Take off belt and motor moves just fine and is strong enough that I cannot turn it by hand.
As I started blind attempts few days ago after my previous post at first there were runaways approximately at 2-3 m/min when going in "positive" direction. Changing pid maxoutput and scalemax values resulted in motor spinning in both direction at 100m/min (which is close to 4K RPM). And I get more or less equal velocity (positive or negative) if I manually set bldc.value to plus or minus 0.2A, (this was suggested by you in some forum thread) so I think that encoder-offset should be if not perfect than at least usable to get at least some motion.
Today I wanted to try with the belt on and it does not move at all. Pid output is saturated, 8i20 current pin value is 30A and motor is not even warm. It seems to me that there is some parameter in the way and motor is not receiving anything even close to 30A. As I mentioned, nvcurrentmax is 750. I am not sure I understand the manual correctly but it seems that this means 7,5A. Is that correct? How do I change that? Is there any other parameter I should look at?

Use a MOSFET to control the wire current and subsequently the temperature, controlled as a spindle so you can adjust it during work.
MOSFET's usually require 10-15V to open fully but there are logic level ones that need about 4V on the gate to fully open, so depending on that you can use the Mesa outputs, there are some caviats there but we'll deal with that when we get there.

This code is not working for RPI 5 it shows some debug error related to permissions, 
error is like:

Debug file information:
Note: Using POSIX realtime
The GPIO line GPIO16 can not be found
hal_gpio: rtapi_app_main: Operation not permitted (-1)
./xy.hal:8: waitpid failed /usr/bin/rtapi_app hal_gpio
./xy.hal:8: /usr/bin/rtapi_app exited without becoming ready
./xy.hal:8: insmod for hal_gpio failed, returned -1
1564
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

Anybody has any idea to solve this problem kindly reply.

I think if you were going to support QTplasmac configs, you would need to review the pncconf code as its not a trivial application

I'm not convinced that codesys or twincat is a standard.
But CIA402 over ethercat is.
When I attended a seminar where Martin Rosten, the head of the Ethercat Technology Group spoke when he was in Australia, the Ethercat standard he described was all around the TCP packet structure and its handling.

I'm still talking with the vendor and realising that nobody seems to know that ethercat is a standard and has rules.

Doing stuff like this creates a mess in the long run. Ethercat is a very good standard and I heard good things about linuxcnc but this makes it look bad tbh.

Now vendors are selling products that don't support the standard it would seem. I think this started in Asia because others appear to be doing it for factory automation there.

There's a reason linux is good and ignoring standards isn't it

linuxcnc-uspace:
Installed: 2.9.0~pre1+git20230208.f1270d6ed7-1
Candidate: 1:2.9.3
Version table:
1:2.9.3 500
500 www.linuxcnc.org bookworm/2.9-uspace amd64 Packages
1:2.9.2 500
500 www.linuxcnc.org bookworm/2.9-uspace amd64 Packages
1:2.9.1 500
500 www.linuxcnc.org bookworm/2.9-uspace amd64 Packages
*** 2.9.0~pre1+git20230208.f1270d6ed7-1 500
500 deb.debian.org/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status

 

It would seem to be the problem you are describing is an issue with the probe basic file browser.
It would be an idea to make that issue known, especially the difficulty in moving through the directory tree.
Whilst your solution appears to work it would appear to be only slightly better than running rsync every couple of minutes via cron.