Advanced Search

I figure you might ask for the pinout from mesa flash so here is that.

I added 12v field power to the 7i77 but still am getting the pin doesn't exist error. I do have a new light on the 7i77 though.

The 7i77 must have field power or the field I/O pins will not be present:

hm2/hm2_5i25.0: IO Pin 003 (P3-15): Smart Serial Interface #0, pin tx1 (Output)  << 7I77 analog out is working as it needs only 5V
hm2/hm2_5i25.0: IO Pin 004 (P3-03): Smart Serial Interface #0, pin rx1 (Input)
hm2/hm2_5i25.0: IO Pin 005 (P3-16): IOPort  << This is the 7I77 digital field I/O. It's not working, likely because 7I77 field power is not present
hm2/hm2_5i25.0: IO Pin 006 (P3-04): IOPort
 

I have it hooked up to a 5 volt supply. Lights turn on. Also need to figure out how to make the 7i84 I have get detected when connected to the 7i74. The 84 has 12v field power

Hey and thanks for the effort!
I tried a sim config and set the "halui.maschine.on" and I get "halui.maschine.is-on" to change state to on. With off it works in the other direction.
I then tried the same thing with my config (pendant off) and it works! When I turn my pendant on things go down hill... I then press the reset button on the pendant and I can get my "halui.maschine.is-on" to get stuck either on or off. If it is stuck, it does not change whith the GUI button either.
This is beyond confusing to me. Why does my cofig do that from version 2.9.5 onward?

Thanks for confirming it´s a bit strange
I´ve now tried again the newer probescreen v.2.9 where I didn´t connect the toolchange pins (this was the initial reason for using the older screen v1). It seems to gerneral work, too. But with a strange behavior like in v1.

Probing in Z seems to work fine. When I touch Probing from X-, Y- the machine starts moving in X+ direction until it prompts "finished without probing..". It should move in X- first, Z down, and then X+ for touching.. Crazy behavior.
In my case it starts directly moving X+ without moving Z..

I allready checkt the macro files. everything seems to be okay. any idea how to debug it?

Hi,

i have something similar implemented in my machine. 
I have door closed signal, door locking signal (combined door sensor and locker). When TC is requested door is free of lock. When door is opened in manual mode when spindel is running. spindel stops. 

Attached you´ll find my hall (linux cnc 2.9.1). Search for door in the hal file (should be at the end). Hope you can recycle something..
 

Many thanks.
I compiled in your magic code in. With a puls-lenght of 50 my problems seem to be gone. This should become the standard toggle2nist.
Many thanks!

Thanks.

Yes, I switched to the generic driver. After studying the nearly 1000 pages of documentation, I didn't see any advantages .
I can configure the converter very well directly.

The tip helped me. I had to remove “name=‘D1’” and add “configPdos=”true".
You have to pay attention to upper and lower case here.

Then there were a few minor things in the ini and hal files. Now my bus is running.
Now I just have to take care of the units.

I've just built the current 2.9 branch (ie 2.9.6) and tested "halui.machine.is-on" reacting to "halui.machine.on" and "halui.machine.is-off", works for me in both tested guis (axis, gmoccapy)

Thanks! I saw your post and started reading it. There's a lot there.

Were you able to replace the resolvers with encoders? Are they part of the motors?

I ask because I found a video of some guy who did a Nakamura LinuxCNC retrofit and he opened up the Fanuc spindle motor and replaced the Fanuc encoder with one he bought off of Alibaba. He had to machine a custom mount for the encoder.

I don't know if the resolver process is similar or if I have to buy all new servos.

I did a Mazak MS15
forum.linuxcnc.org/show-your-stuff/32784...-15-retrofit?start=0

can you please show us the parameters you used?
'loadrt classicladder_rt .....'

If you open one of the sim configs and check "halui.machine.is-on" does it go true when you enable the machine with the gui button?

Hello,

Thank you for your effort and patience.
I didn't expect it to be so easy either.
I searched the code on the net to try whether it could work with the camera before I gave any nonsense.
I just let the whole thing run in studio code.
Since I hardly have any idea from programming, I was glad to have something to run at all.
My thought was that you could do something like that in the scaling function and to simply make it handlebar via the qtdragon.pref.
What Qtdragon shows, I noticed when comparing the image with other programs and even if you use the zoom function, the image becomes pixelated very quickly.
Various Linux tools first read only 640x480 as a kind of standard.
v4L2-ctl --list format-ext shows the following resolutions:

640x480
352x288
320x240
176x144
160x120
800x600
1280x960
1600x1200
When I start GuvcView, the camera is first displayed 640x480, it can then select and the image quality changes.

Small addendum, you can see it even better:

Qtvcp -d -o Cam number = 14 cam_align

Two cameras are just connected here:
Port 1 Andostar
[QTvcp.QTVCP.WIDGETS.CAMVIEW_WIDGET][DEBUG]  Port 1 is working and reads images (480.0 x 640.0) (camview_widget.py:520)

Port3 webcam
[QTvcp.QTVCP.WIDGETS.CAMVIEW_WIDGET][DEBUG]  Port 3 is working and reads images (480.0 x 640.0) (camview_widget.py:520)

Thank you for your efforts and all the best, Frank.