I wonder how this could be damaged?
it has never been connected to anything else but 5 volt, Ethernet, one encoder and one analog out? It has never been installed and has never left the table.

MRx, nice! what hardware are you using?

and i'm still working on the new platform, also with an ethernet interface... now i can have all supported mitsubishi protocols running simultaneously on a single zynq 7010 core ok, 5 of them - parallel bus (MR-S), 2 copper serial (SSCNET I, II, MELDAS 5/6), 2 fiber (SSCNET III, III/H, MELDAS 7, . as all of them share the same multiple-of-222us cycle time...

still have the second processor core and a spare PTPv2-capable 1Gb ethernet port to try the CC-Link IE/TSN thing to complete the picture...

If you set all PID values to 0 and you still get 1V outputs  from the 7I97T analog outputs
,the 7I97T is likely damaged

Sorry, mismatch between advertised clock and real clock
so the baud rates were all off...

 Denser configurations like this have a slower clock to meet timing
and this is the first time I have made on of these configs, and I had
not quite gotten al the ducks in a row...

This _should_ be better

 
 

Hi PCW,Thanks for that. There's a problem with the sserial port; with the previous firmware (attached), the system as it's currently wired inc. the hal line:
loadrt hm2_eth board_ip="10.10.10.10" config="num_encoders=6 num_pwmgens=6 sserial_port_0=0000000" works and allows us to reference the 7i84 e.g.: hm2_7i97.0.7i84.0.3.output-00

Changing only the firmware to the one you posted above, lcnc fails to start with error:
twopass: Error in file ./morb01_IO_7i84.hal:
    Pin 'hm2_7i97.0.7i84.0.3.output-00' does not exist

this is with all wiring identical. close checking of the readhmid output and manuals suggests that the sserial port settings should remain the same - is this expected? 


 

Hi there
I am retrofitting a giant 7 meter and 7 ton Homag BMF 411.
When it left the factory in 2005 it was equipped with Indramat servos (today Rexroth) and Rexroth DKC 03.3 drives with sercos I communication. 
With a great deal of willingness from our local Rexroth technicians i managed to reconfigure the drives to analog com and now the drives are updated with new firmware ready to be re-installed in the machine.
I have managed so far to connect the 0 joint -x axis-  to my mesa 7i97t ethernet card and i can see the DRO increasing/decreasing respectively when I rotate the motor by hand. So all in all a first table setup with one motor no limit switches, motor brake and enable signals are still not coming from linux but directly from UPS.
Here are my problems:
1  When I enable the drive the mesa card throws out 1 volt to the analog pin and the motor starts turning at a speed that looks OK like 10% of speed max.
2. When I jog the motor in continuous mode the x axis DRO counts up 0,18 mm when pressing and another 0,18 when releasing the tab - same result if i use the jog arrows in axis.
Any ideas?
I am not a linux specialist - in fact this is my first time putting fingers to a linux pc but i have been working with CNCs for 3 decades 
  

I have a 3 axis mill/router that I primarily use for woodworking/plastics. It's an older machine but upgraded/rewired and running great with LinuxCnc 2.9.7 and QtDragon. It has a manual tool change spindle that I'm happy with but I'd like to automate the process of changing tools a little. Currently, I output a separate nc file for each tool that I run on a job and I manually adjust the z-height after each tool change and reset the G54 z-zero before starting the next nc file/toolpath. It works but it's a little slow and error prone.

I have purchased a tool setter switch, mounted to my machine bed, wired it up to my 7I96s and it seems to work (electrically). However, I'm a little confused on what the best workflow is. Ideally, I'd like to make this as idiot proof as possible with some simple macros. Before I get started I figured I'd ask if anyone else has some macros/ideas to share.

For each job:

• Manually install the starting tool and zero it to the machine bed or work piece top
• Start the job
• Automatically move to the xy position of the tool setter to measure the z offset of this first bit
• For each M6 tool change:
  • Automatically move to the xy position for tool changes (front center)
  • Manually change the tool and confirm change complete
  • Automatically move to the xy position of the tool setter to measure the z offset of the next bit
  • Automatically calculate the difference in height between the new tool and the 1st tool and update G54 z zero
  • Automatically continue job 

I'm not sure if this is more of a configuration or QtDragon workflow question. I also realize that to everyone with a tool carousel, this seems like caveman operation. 

Bonjour, 
Je construis une CNC multifonction avec 5 axes , et 2 axes rotatif fraiseuse et pas a pas.
J ai actuellement 2 cartes chinoises mach3 des NEMA des DM556 . Un pc DELL optiplex 7010 .
Le pc n' a pas de port parallèle, j' ai donc commandé une PCIe 2 ports puce ASIX 9865 , impossible de la faire fonctionner, elle n' ai même pas reconnue sûr le slot pcie. Sûr le slot bleu PCI+PCIe elle est reconnue "lspci -v" mais , je me retrouve avec quatre adresses.
J ai essayé toutes les combinaisons possibles dans le "Hall" .
J en ai conclu que il y avait un problème de compatibilité.
Ma question est donc :: que dois-je choisir comme système, continuer a chercher des cartes PCI ou PCIe/parallèle ou une autre solution tel que les cartes MESA ? Pour les quelles je n' ai aucune connaissance.

Merci de vos réponses 
Florent 

 

Okay, will try that when problems retturn. Thanks!

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.8
Machine configuration directory is '/home/ricco/linuxcnc/configs/mill_touch_sim'
Machine configuration file is 'mill_touch.ini'
INIFILE=/home/ricco/linuxcnc/configs/mill_touch_sim/mill_touch.ini
VERSION=1.1
PARAMETER_FILE=emc.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
DISPLAY=qtpyvcp
COORDINATES=X Y Z
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./mill_touch.hal
Found file(REL): ./custom.hal
Starting TASK program: milltask
Starting DISPLAY program: qtpyvcp
Can't execute DISPLAY program qtpyvcp  
Shutting down and cleaning up LinuxCNC...
task: 29 cycles, min=0.000006, max=0.012605, avg=0.005740, 0 latency excursions (> 10x expected cycle time of 0.010000s)
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
Unexpected realtime delay on task 0 with period 100000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
3180
3212
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

How did you design the process?
You write the values for homing in 0x6041 and 
then set a bit for start homing, right?
The servo should then respond with a status bit that can be monitored.

Or I have three other suggestions that could be considered 
1. 
After writing 0x6041, read the register again and check the consistency.  Then start homing and monitor a status bit

2. 
Monitor the axis movement.
The axis must start moving after start homing.
A minimum distance could be specified here, otherwise an error will occur.

3.
Gantry version
The axis positions could be compared with each other.
If the difference is too great, then there is a malfunction.

PS: There was once a project called “Ethercat auto configurator.”
Is this still being pursued?

Today all is functioning normally again. Ran a 30 minutes program without errors. So I don't know what happened yesterday, maybe I need a new pc.

remember limit switches need to stay triggered to the end of travel.

Hakan wrote:

From what it looks like, the only way out from homing is that is finishes.
This could probably be expanded to include error states and whatever can occur.

 

Back after my IP being banned for a week! (Thanks for letting me out of Jail Andy!)
Maybe thats an oversight. the homing process is managed by  the cia402 state machine. Homing completed is returned in Bit 12 (from memory) and if it errors, that is returned in bit 13). The function of these bits are often not well documented but its really standard cia402 behaviour.