Advanced Search

That is correct. The ones i have worked on are mostly newer ones and have straight X and Y axis. Do you have the manuals for it? All the geometry should be specified there. What year is it?

Building 7i92 firmware for a custom board. I've had to play around with

Turn on board everything seems ok, user leds count packets
IP set to 192.168.1.121
Responds to pings
When jumpered for bootp an ip address is received and I can ping it.

This has me stumped 7i92 mac is ff:ff:ff:ff:ff:ff

$ mesaflash --device 7i92 --addr 192.168.1.121 --verbose
Unsupported ethernet device ��������������������z at 192.168.1.121
No 7I92 board found

��������������������z bit will change on each mesaflash run


Wireshark dump

32    7.057855358    192.168.1.20    192.168.1.121    UDP    46    50697 → 27181 Len=4
Frame 32: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface ens5, id 0
Ethernet II, Src: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.1.20, Dst: 192.168.1.121
User Datagram Protocol, Src Port: 50697, Dst Port: 27181
Data (4 bytes)
    Data: 01420001
    [Length: 4]

33    7.058018908    192.168.1.121    192.168.1.20    UDP    60    27181 → 50697 Len=4
Frame 33: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface ens5, id 0
Ethernet II, Src: Broadcast (ff:ff:ff:ff:ff:ff), Dst: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac)
Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.20
User Datagram Protocol, Src Port: 27181, Dst Port: 50697
Data (4 bytes)
    Data: fecaaa55
    [Length: 4]

34    7.060132328    192.168.1.20    192.168.1.121    UDP    46    50697 → 27181 Len=4
Frame 34: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) on interface ens5, id 0
Ethernet II, Src: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Internet Protocol Version 4, Src: 192.168.1.20, Dst: 192.168.1.121
User Datagram Protocol, Src Port: 50697, Dst Port: 27181
Data (4 bytes)
    Data: 885d0000
    [Length: 4]

35    7.060285405    192.168.1.121    192.168.1.20    UDP    60    27181 → 50697 Len=16
Frame 35: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface ens5, id 0
Ethernet II, Src: Broadcast (ff:ff:ff:ff:ff:ff), Dst: UniversalGlo_3e:7d:ac (cc:52:af:3e:7d:ac)
Internet Protocol Version 4, Src: 192.168.1.121, Dst: 192.168.1.20
User Datagram Protocol, Src Port: 27181, Dst Port: 50697
Data (16 bytes)
    Data: ffffffffffffffffffffffffffffffff
    [Length: 16]

I'm guessing the data in the last packet isn't right.

 

hello,

this topic is quite complex if you dive in it.
First of all, the mentioned github repo is intended for 3d printing, so maybe thats why it works with positive coordinates, which is usual for 3d printers.

i would recommend checking out DauntlessAq fork and PR, where he corrected some issues:
github.com/scottalford75/LinuxCNC-3D-Printing/pull/8

There is description of the issues.
 

I would like to suggest a feature to fine tune ohmic probing.
Problem: When I set the probe height to an optimal setting for a thin steel setting, it will be too low for thicker steel, and set for thick steel it has excess travel.
My solution would be to add the material thickness to the plasmac.probe-start-height.
Keep the probe height setting function the same, but add a new setting into each material entry for material thickness.
To try to see if it would work, I used the puddle jump delay setting and used the sum2 function to add that number to the probe height. It seemed to work as expected.
With material thickness added the probe height should be more consistent with the top of the material.

This is the code I added to the custom_postgui.hal file.

Thanks, that's exactly what I'm looking for. We'll be experimenting with it.

I know the Y axis is interpolated. So for a straight Y movement 90° to X the X axis need to move as well. Is that correct ?

yes switch will be necessary but my pain was that mixing stuff ... and therefore I erase all switches out to separation possible cases of mixing...

I will try and let you know

thanks

The ? would always be Y. I havent worked on these for a while, but generally, axes stay the same when shifting between lathe and mill on mazaks, but geometry switches between diametral/radial.

Fun project! Integrex's are great machines!

Bonjour,

J'ai câblé un switch sur le pin d'entrée n° 11 de ma carte d'axes.
Je voudrais exploiter cette entrée dans un programme avec la condition if.

Comment faire pour affecter cette entrée à une variable utilisateur, par exemple 40 ?

La ligne pour cette entrée dans le fichier hal :
net din-01  <= parport.0.pin-11-in
La ligne du programme avec if
o100 if [#40  EQ 1]

Merci d'avance

 

Excuse my crude model of the Integrex, but could someone tell me if my axis naming is correct for a lathe configuration?
And how is the axis called with the "?". Of Course for a Mill configuration it would change. Would be happy for input

Hi all!

I have been trying to get a Z compensation thingy working for a while. 

github.com/scottalford75/LinuxCNC-3D-Pri.../master/compensation

I have gotten the script working, in the way that it is incorporated in LinuxCNC, and it reads my probe data, sorta. I have two problems with it.

First problem: It doesnt read negative coordinates in X and Y. It only understands lower left corner being zero in the gcode. Which is a problem, since my machine zero is in center of worktable, and i make all my gcode with zero in center. I have worked like that for ages, and i dont feel like changing my workflow. 

Second problem: The outputed coordinates only work from machine zero. It doesnt follow if i have a work offset active. 

Has anyone had the same problems? This is over my skill level, and i cant get it to work.

I am attaching a number of files. Compensation.py is the script i am using now. probe-results.txt has only positive coordinates and works. probe-results2.txt has both negative and positive, and does not work. Or, it works for a while if i only move in positive area, but after a while the whole compensation just dies and i have to restart LinuxCNC. Z_level_compensation.py is a file i found in another thread here, that i believe morley(?) has modified. It is based on the script i am currently using, but it looks like work offset has been fixed. I have not gotten this script to work on my system, but maybe someone can tell me how to fix my problems based on that. 


 

tommylight wrote:

Usually omitting or deleting lines with HOME_...._velocity in the ini file and editing the homing and limit lines in hal is all it takes,

It's usual to retain the lines, but set the two velocities to zero. Omitting probably works too (they will default to zero) but actively setting to zero looks less like a mistake. 
 

endian wrote:

I have not using any kind of global variables 

I think you are, look at line 159:

mode_selection is a static global in the code. 

I don't know for sure if that is enough to cause the problem? 

it looks like mode_selection should be a local variable (actually, make it a parameter so that you can debug using it)

Also maybe consider using a "switch" command on mode_selection rather than repeated "if (mode_selection == ##) "

timo wrote:

 because I might have damaged a drive or two without beeing aware of the importance of the wiring.

 
A cage-clamp terminal done up nice and tight with the cable not actually inside the clamp is a popular way to blow up a drive. Give the wires a good tug after tightening the clamps.

Kieran wrote:

How's the rigidity of the harmonic drive? 

It seems OK. The HD website quotes values for torsional stiffness, but to be honest I don't know what value would be appropriate for a milling machine, so the numbers aren't useful to me. 

But I frequently use it just as a handy way to mount round stock and have noticed no issues.