Pokeys

Thats just a warning. The error which prevents compilation is

i see, anyway it is the same file, that has been added at that comit.

as soon as i'm at home i can check if on my system the file already exists.

I'm not sure if, a workaround might be to exclude it in makefiles.

what i found in actual files in bitbucket SOCKADDR is defined in PoKeysLibCoreSockets.c

#if defined(__FreeBSD__) || defined(BSD) || defined(__APPLE__) || defined(__linux__)
#define USE_GETIFADDRS 1
#define SOCKADDR struct sockaddr

#include <ifaddrs.h>

uint32 SockAddrToUint32(struct sockaddr * a)
{
return ((a)&&(a->sa_family == AF_INET)) ? ntohl(((struct sockaddr_in *)a)->sin_addr.s_addr) : 0;
}
#endif

which compilation seemed ok according to logfile

ozisthebest@debian:~/mbosnak-pokeyslib-7a079bad8dbe$ sudo make -f Makefile.noqmake install
[sudo] password for ozisthebest:
gcc -fPIC -c -o PoKeysLibCore.o PoKeysLibCore.c
gcc -fPIC -c -o PoKeysLibCoreSockets.o PoKeysLibCoreSockets.c
...

so i assume that the condition "#if defined(__FreeBSD__) || defined(BSD) || defined(__APPLE__) || defined(__linux__)" did not match due to some reason.

.. unfortunately i currently have insufficiant knowledge to dig deeper in that issue. (i would have asumed that at least "defined(__linux__)" should be true)

to fix it i think we should report that problem at bitbucket.org/mbosnak/pokeyslib/src/master/

Thanks for that the help. Clearly something is not being set right in the environment for some reason.
I tried a couple of edits to PoKeysLibCore.c but it still failed, 
So I added to PoKeysLibDevicePoKeys57Industrial.c after #include "stdio.h" and it worked

Thanks again!

Actually thinking about it those #defines should most likely be made in the h file, not the .c file as it won't be included in the other modules

Thanks for all of the help so far, I was able to get the build to work with the change from Rod and then set about getting the board to communicate. I have followed all of the steps on page 10.

I'm now getting the same kind of errors that MATZE-ATZE-SCH was getting. My pokeys board is on, red and green light. The correct devSerial (51459) is loaded (grabbed it from the pokeys environment in windows where I also confirmed that all of my buttons and encoders are correctly wired). But, I am not getting an alive or error pin active when I check it in HAL Configuration.  I have tried all of the COMP files which have been uploaded, with the most recent being the comp attached to this post: 

forum.linuxcnc.org/24-hal-components/298...net?start=130#250534

I am getting a deb (with that comp file) of 10020 which I think means the USB has not connected and it is now waiting for UDB? I I've tried unplugging and replugging the USB connection (I am using a pokeys57U), different COMP files etc.

Any suggestions as to what I might be doing wrong?

ChapEng wrote:

I am getting a deb (with that comp file) of 10020 which I think means the USB has not connected and it is now waiting for UDB? I I've tried unplugging and replugging the USB connection (I am using a pokeys57U), different COMP files etc.

Any suggestions as to what I might be doing wrong?[/url]

you are totally right, "dev = PK_ConnectToDeviceWSerial(devSerial, 2000)" did not work, so it tries to connect via UDP. within code you may try to increase the timeout parameter in that call and recompile.

while(dev == NULL)
{

dev = PK_ConnectToDeviceWSerial(devSerial, 2000); //waits for usb device
deb=10010;
if (dev == NULL)
{
deb=10020;
dev = PK_ConnectToDeviceWSerial_UDP(devSerial, 5000); //waits for udp device
}
}

if that still does not work, i would check if USB ports are basically working, and it can find the Pokeys57U using lsusb.

if that is fine i would somehow check if the devSerial used at that command is still right, within the comp.
you may use "Test HAL command" (in HAL Tree Area) to manually send this command.

setp pokeys.0.devSerial 51459

BR
Dominik

Thank you for the suggestions.

I tried upping the wait time (6000) and no luck. So I moved onto checking the lsusb (I am fairly new to linux, you've taught me a new command, though I should have had the troubleshooting foresight to google that one myself). I've attached my screenshot from the lsusb results, first iteration is without pokeys connected, second iteration the pokeys is connected (Bus 001 Device 005) but you can see it has no listed name. Suspecting that the device should have a name I connected my USB-RS485 module in the third iteration (B1D6). I tried a few different USB ports and had the same result with no name.

I've also included a text dump of "lsusb -v", if that is useful.

Do these results suggest there is something wrong with the library install and that linux isn't identifying the board properly (beyond "there is something there")?

Matt

So today i found some time to check this on my machine (raspberry Pi4).

i usually used Ethernetconnection, but on Pokeys57CNC i also have te possibility to connect via USB - which i did now.
and it is listed in output of "lsusb -v". - so i think that's a precondition to get the comp-file working.

 

for pokeys57U i'm not sure if it needs external powersupply, or try a different USB-port, and/or USB-cable.

just to be sure - i also updated pokeyslib as provided on bitbucket - and the compilation issue was reproducible.
(and i reported that to Matevz who seems mainting that library)

after applying the workaround described by "rodw" i can still get my comp-file working when connected using USB Port.

BR
Dominik

edit:
feedback from Matevz

Hi, Dominik

Thank you for contacting me. The file PoKeysLibDevicePoKeys57Industrial.c was added in the last published version, but it was only used in a Windows environment. You can ommit this file during compile for now (remove it from the Makefile).

as i plan to continue working on homing-topic in my COMP-file (mid of next month - if sensors&optocouplers arrive) i wonder if there is someone who might support me on that topic.

Actual status is as follows:
- pins for LimitP, LimitN and Homeswitches are available (an read inputs as parametrized on pokeys side)
- Pin-IDs, Acceleration, Velocities as parametrized in LinuxCNC - ini file (i added some entries), are being read in COMP file and pokeys-pulse engine is parametrized accordingly.
- Steppers connected to Pokeys-PulseEngine outputs are moving in controlled by LinuxCNC-Compfile.
- Status of PulseEngine is read and can be set (currently interacting with linuxCNC at EStop, Running, Stopped)
- Axis State is being read.
- distances& velocities as configured in linuxCnc using [Unit/sec] (mm/s in my case) are being translated/converted to [ticks/sec] for pokeys

i got an example on how to trigger homing procedure on pokeys (attached pokeyshoming example.c) - this should be basically no problem to implement similar behaviour in my component. 

according to pokeys PulseEngine Manual the pokekeysshould react as:

Homing: homing mode is activated. In this mode, one or more axes can be homed. The selected axis (or axes) moves in negative direction at predefined fraction of the maximum speed until the home switch is tripped. Then, the direction is changed to positive and speed decreased to half the previous speed. When the switch is tripped, the internal position counter is reset and the axis is commanded to stop. This operation does not include moving back to position 0. The state of homing procedure is reflected in axes states.

anyway i assume some bad interferences with linuxcnc e.g. if the position feedback is suddenly changing set to "0" or a limitswitch is being triggered.

in LinuxCNC wiki i found that there's an option for "intermediate homing" which seems an option to prevent such interferences.
 
I think that here are still some issues which i did not think about, and i'm still not sure if it is the right direction to start with, so i would appreciate any hints & tipps.

BR
Dominik

(Pokey57CNC manual mentiones some "Homing algorithm configuration" but i think on that side i need to contact PoLabs to get a better understanding)

I can't help you with as I don't have the hardware. But I can put you on the right track!.
Homing is managed in Linuxcnc by homing.c
github.com/LinuxCNC/linuxcnc/blob/master.../emc/motion/homing.c

Master branch has recently released the homecomp.comp compoonent
linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html
and the source file here github.com/LinuxCNC/linuxcnc/blob/master...onents/homecomp.comp
The purpose of homecomp is to give a method to override homing.c behaviour to build a custom homing behaivour

You should also look at Domminic Braun's ethercat cia402.comp and supporting hal file github.com/dbraun1981/hal-cia402
which predates homecomp and also attempts to deal with hardware which homes externally. He also deals with the conversion of motion units between Linuxcnc and external hardware. Look at how he uses read and write functions. This might be able to be done in halcomp as there are procedures that read all pins and writes all pins.
Your homecomp needs to be able to deal with following errors that will ocur when the extenral drives move without lcnc's knowledge. This can be done by equating the feedback position with current position during external homing.
There are a large number of homing states that can be skipped or ignored when external homing is done so you homecomp basically just needs to initiate homing and wait intil homing is completed ,Tell Linuxcnc you are homed, and then let Linuxcnc continue on.

God luck with this, its complex because in a homecomp, you need to deal with all joints at a time where a component like cia402.comp has a seperate instance of the component for each drive being homed...