Advanced Search

Lcvette,

Thanks for the help.

I'm unsure why the file names on the forms now have the 2025-01-09 attached. It must have been added when I uploaded them. They match what I have in the ini file except for the postgui file name error. I thought I had changed that one. I have made the suggested changes and still can't launch Probe Basic. getting the error "Can't execute DISPLAY program probe_basic  "





 

Anything above Core2Duo should do, 8GB of RAM (works OK with 4GB) and 32GB of disk space (HDD or SSD or NVME).
See here for some more info:
forum.linuxcnc.org/18-computer/38838-har...ency-tests-used-pc-s
And see here for some laptops that work, just do not bet on it as you might find the same model that does not work, i know i did
forum.linuxcnc.org/18-computer/54369-use...ernet-boards?start=0

Is there any requirement for building a Linuxcnc computer.

hd size
ram size

thanks john
 

I/O 34 and 38 are  still available  as GPIO
(1 differential input and one differential output on the 7I74)
There might be room for some simple feature on those pins
(say PWM for output  or encoder 'A' pin for input)

Hi,

I tried the other channels on the 7i74 today,
all of them work as they should.
Thanks again.
I noticed afterwards that in the thermal output I attached, IO 34 and 38 have no function, I assume that in different situations these would be RXData0 and TXData0.
So I should have noticed the fact that channel 0 is not available on the 7i74 in my case.
 

I don't think there is much advantage to returning the rotary encoder
data to LinuxCNC.  I think for the uses of the linear encoder position mode
is OK, basically the linear encoder would be of most use compensating for
ball screw errors and thermal expansion which can be handled by LinuxCNCs
relatively low bandwidth control.

The RS-485 adapter should work, wiring would be:

PktURDataPin  <= RO   
PktUTDataPin   => DI
PktUTNDrvEnPin => DE
GND => RE

Note the N in PktUTNDrvEnPin

(the firmware must be built with this pin in the pinout file to have the
proper drive enable polarity)

Did you look at the relayboard.mod example?
Its probably closer, not for addresses but for bit I/O:
(look an the input definition)


/* Modbus definition file for a 4-channel relay board found on eBay */

/*
The format of the channel descriptors is:

{TYPE, FUNC, ADDR, COUNT, pin_name}

TYPE is one of HAL_BIT, HAL_FLOAT, HAL_S32, HAL_U32
FUNC = 1, 2, 3, 4, 5, 6, 15, 16 - Modbus commands
COUNT = number of coils/registers to read
*/

#define MAX_MSG_LEN 16   // may be increased if necessary to max 251

static const hm2_modbus_chan_descriptor_t channels[] = {
/*  {TYPE,    FUNC, ADDR,   COUNT, pin_name} */
    {HAL_BIT, 1,  0x0000, 8,     "state"},
    {HAL_BIT, 2,  0x0000, 8,     "input"},
    {HAL_BIT, 5,  0x0000, 1,     "relay-0"},
    {HAL_BIT, 5,  0x0001, 1,     "relay-1"},
    {HAL_BIT, 5,  0x0002, 1,     "relay-2"},
    {HAL_BIT, 5,  0x0003, 1,     "relay-3"},
};


/* Optionally #define DEBUG to aid with troubleshooting.
   Use 3 to see a lot of information about the modbus
   internal workings. 1 is default (errors only)                    */

 

Hi.
I would like to come back to you about the best way to have a closed loop with a linear scale and a servodrive-motor combination (which has a closed loop already)

Please take a look at attached picture.
The motor has an encoder which is connected to the drive.
The Mesa-board sees the exact position of the table, and should keep giving commands to the drive, untill position is reached. (I expect)

The loop between motor-encoder and drive is the fastest, and not influenced by any speed of the Mesa.

What is your opinion of the considerations I have:
1. Is it smart to use the drive-outputs of the encoder to the Mesa-board? (And for what purpose)
2. Should I controll the drive in POSITION-mode or SPEED-mode?
 
Thanks, and with kind regards.

That's even better!

Added video to Lenovo T470
forum.linuxcnc.org/18-computer/54369-use...hernet-boards#313954