Advanced Search

Das ist sehr merkwürdig.

Hier funktioniert es mit der Gebietsschemaeinstellung de_DE.UTF-8.

Ich werde nachsehen, ob es etwas Offensichtliches gibt, aber ich glaube, das übersteigt meine Kompetenz.
 

Good and bad news. Bad news first; I've put back 5.4.258 temporarily. I really terrorized myself yesterday when I saw it broken (sweats man lol), knowing I desperately need this mill all of this coming Saturday and Sunday (important project). And so the bad news is I won't be able to test this out, at least not before the coming week.

The good news is; I'll surely reinstall 5.4.279 and give it another go. Let's get to the bottom of this, if not only to improve the making of RTAI. I'll update in 4~5 days max.

Side note. I've just placed a Dell Optiplex 780 w/ a built-in parport on order to backup with. That way I can test on real hardware before making changes to the production-ready kit - yesterday's self-terrorism just can't happen again.

though i've never seen those MR3-V3 amps nor i could find a manual, i guess they should be rather similar to MDS-A/B/C-V.
the manual for the later says clearly that alarm 11 means two axes are set to the same address. which is clearly not the case. i could suspect a faulty rotary switch, but never seen one failed.

a question - is the "11" display blinking? does the drive also shows the offending axis no? alarms usually shown as F1 -> 11 -> F1 -> 11 ... where F1 is axis 1 (rot switch set to 0)

also, i remember some drives display a static "11" or "12" early on boot when something really bad has happened. like a corrupted flash, RAM test failure etc.

"AC" on the second drive means it has received a handhake from the controller, but the controller does not proceed with initialization sequence because it probably waits for the other axes to answer first.

at the command line

halrun
loadrt pendantjog names=mypendant
show funct

will probably answer the question

this might work..in tmc/python/tormach_lathe_ui.py or tormach_mill_ui.py

look for this phrase..

# Escape used to stop certain UI tasks.
if kv == gtk.keysyms.Escape:
self.error_handler.log("ESC key - queueing stop event")
self.enqueue_button_press_release(self.button_list)
self.tool_descript_entry.shutdown_view() # if active terminates the tool description overlay
self.profile_renderer.update() # if active terminates a zoom view on the profile render
tooltipmgr.TTMgr().on_esc_key() # if active end the current tooltip.
return True

#w key on keyboard
if kv == gtk.keysyms.w:
self.sliders.set_slider_value(100)
return True

i use this addition for a jog encoder and spindle,feedrate,maxvel panel encoders...this version does need variables declaring earlier in the program but you might get the idea...

#--user keys

---

#add self.override = [100,100,100] #new list for override variables after init_sliders line 588 o this version

# MOD1_MASK indicates the left alt key pressed

if event.state & (gtk.gdk.MOD1_MASK): #MOD1_MASK = left ALT key

#panel encoders

if kv == gtk.keysyms.u:
self.override[0] = self.override[0] + 1
if self.override[0] > 200:
self.override[0] = 200
self.sliders.set_slider_value(self.override[0])
return True

if kv == gtk.keysyms.v:
self.override[0] = self.override[0] - 1
if self.override[0] < 0:
self.override[0] = 0
self.sliders.set_slider_value(self.override[0])
return True

if kv == gtk.keysyms.w:
self.override[1] = self.override[1] + 1
if self.override[1] > 200:
self.override[1] = 200
self.sliders.set_slider_value(self.override[1])
return True

if kv == gtk.keysyms.x:
self.override[1] = self.override[1] - 1
if self.override[1] < 0:
self.override[1] = 0
self.sliders.set_slider_value(self.override[1])
return True


if kv == gtk.keysyms.y:
self.override[2] = self.override[2] + 1
if self.override[2] > 100:
self.override[2] = 100
self.sliders.set_slider_value(self.override[2])
return True

if kv == gtk.keysyms.z:
self.override[2] = self.override[2] - 1
if self.override[2] < 0:
self.override[2] = 0
self.sliders.set_slider_value(self.override[2])
return True

#jog speed

#jog speed 1
if kv == gtk.keysyms.a:
self.sliders.adjustment.set_value(1)
if kv == gtk.keysyms.A:
self.sliders.adjustment.set_value(1)
return True

#jog speed 10
if kv == gtk.keysyms.b:
self.sliders.adjustment.set_value(10)
if kv == gtk.keysyms.B:
self.sliders.adjustment.set_value(10)
return True

#jog speed 30
if kv == gtk.keysyms.c:
self.sliders.adjustment.set_value(30)
if kv == gtk.keysyms.C:
self.sliders.adjustment.set_value(30)
return True

#jog speed 50
if kv == gtk.keysyms.d:
self.sliders.adjustment.set_value(40)
if kv == gtk.keysyms.D:
self.sliders.adjustment.set_value(40)
return True

#jog increment

#increment jog x0.01
if kv == gtk.keysyms.g:
self.enqueue_button_press_release(self.button_list)
if kv == gtk.keysyms.G:
self.enqueue_button_press_release(self.button_list)
return True

#increment jog x0.1
if kv == gtk.keysyms.h:
self.enqueue_button_press_release(self.button_list)
if kv == gtk.keysyms.H:
self.enqueue_button_press_release(self.button_list)
return True

#increment jog x1
if kv == gtk.keysyms.i:
self.enqueue_button_press_release(self.button_list)
if kv == gtk.keysyms.I:
self.enqueue_button_press_release(self.button_list)
return True
#incremental jog

#incremental jog
if kv == gtk.keysyms.j:
self.set_keyboard_jog_mode(linuxcnc.JOG_INCREMENT)
if kv == gtk.keysyms.J:
self.set_keyboard_jog_mode(linuxcnc.JOG_INCREMENT)
return True

#continuous jog

#continuous jog
if kv == gtk.keysyms.k:
self.set_keyboard_jog_mode(linuxcnc.JOG_CONTINUOUS)
if kv == gtk.keysyms.K:
self.set_keyboard_jog_mode(linuxcnc.JOG_CONTINUOUS)
return True

#reset

#reset
if kv == gtk.keysyms.s:
self.enqueue_button_press_release(self.button_list)
return True


#--end user keys

---

panel encoder send a keypress for each indent ...




sorry for pasting code but i can't remember how to wrap it!...

Dorro

can you post your existing hal?...

I remapped the door switch to a physical input on my lathe, the tool changer side of things has a pwm (period measurement) output, a start motion output and a tool change complete input, I used an arduino to handle the toolchange logic...

Its probably expected due to the laws of physics. Without G64, motion will set a large enough arc so it does not have to change the cut velocity.
With G64 you are telling the maximum deviation that is permissible so the tool has to slow down due to the laws of physics to meet your settings.
 

NickH wrote:

Successful install here Bari. Now to get Ethercat working.

From memory PREMPT_RT is a prerequisite for ethercat. In any case without a base thread with ethercat, there is not really a case for RTAI so it should not be an issue.

I have some tricks here to manage latency docs.google.com/document/d/1jeV_4VKzVmOI.../edit?usp=drive_link
 

I don't understand this error.
I wrote the attached custom component to decode a MPG I use.
It compiles fine, loadrt works perfectly and the components pins can be seen in halshow at this point
but when I use addf, it raises an error
It does not matter if I use names= or count= when  using loadrt

Any ideas would be really appreciated. I tried decoding this in hal but gave up as its very messy.

Hey Mecanix, are you able to start and close the latency histogram without rebooting? If not, try a more simple test. The RTAI testsuite is built-in and you can try running that as well.

It's: /usr/realtime*/testsuite/run (Ctrl+C to cancel)

Those look like standard analog drives,

The real trick is figuring out the 14 pin connector pinout

The D41-17443C seems more common and probably has
the same pinout

Have you tried contacting CMC?

Good work. When I had a quick look at the document, I thought that clearing the encoder might need to be done in a custom component becasue there is a sequence of bits that needed to be set in a specific order.

The PWM settings should just be setting SDOs Good luck!

That should be the numbers above.I did get some more pictures though.see attached. I can hook the large plugs back up if need be but most goto what I’m assuming is the control board mounted to the front.  

drives 
   

No Comments ?
Ok, how about this:

That's not so easy.
You shouldn't turn the rotary switches on the amplifier. This is how the axes are assigned in the controller. Alarm 11 on AMP1 says that the axes are not set correctly, but the solution is not to turn the switches, but to find the cause of the alarm. AMP2 says AC. This indicates that AMP2 has not yet spoken to the controller. I suspect that the controller no longer knows how many axes it has. The battery is probably empty and the parameters have been deleted.
I would check the battery and then see if there is a backup of the parameters somewhere. Or you might be lucky and someone at Mitsubishi Electric still knows about it and can help you. Here is the contact
www.mitsubishielectric.com/en/contact/index.html