Advanced Search

My 3-axis mill operated for over a year with LC 2.8.4 on a RPi 4B 4GB.
Then I tried to get the WiFi working. failed the SD card, so started to install LC 2.9.2 with a new SD card.

Problems from the start resulted in me changing to a RPi 4B 8GB, propped up outside the cubicle.

Now, when pinging, I get serious packet loss.
All addresses etc correct as I have had Axis opening on occasion.
The original installed ethernet cable is 250 mm long, and I have a general-purpose spare 10 m long on a spool.

With either cable connected, either way around, finger stressing the connection at the 7i96 socket interrupts packets.
The same stressing at the RPi socket is reliable.
Sometimes, with a bit of stressing, the monitor LED on the 7i96 socket extinguishes.
Sometimes packets will start on the ping, but other times not, with a bit of stressing then starting the packets.

It would appear the Socket on the 7i96 is the problem.

Any suggestions ?

John.

what kinda of signal is it looking for linuxcnc side? dont know how well the velocity pin will work, but we can for sure count, it outputs the encoder as a float

Hello guys,
I'm trying to retrofit 1986 TOS FGS32 CNC - 3 axis milling machine recently driven by Heidenhein TNC155.
I bought Mesa 7i97T and 7i84 cards and I fitted EXEs for scales and connected basics - hydraulics, oil pump, brakes, spindle and analog outputs to Simodrive 610 - motion driver.
HAL files are from Mesa Configuration Tool II.
Scales works well.
My problem is once I run machine in LinuxCNC (F2), all servos starts slowly moving. On all analog outputs is 10mV (always, even with LinuxCNC switched off). I've tried watch values in halshow, but I can't find (or maybe it's that problem) variable which controls analog output - for example these two variables was always 0:
hm2_7i97.0.pwmgen.00.value
motion.analog-out-00
FERROR and MIN_FERROR are intentionally high because of tests i made.
Do you have any suggestions how to solve this problem?
Thank you in advance

Here i go again bursting bubbles ...
If it is an incremental encoder, and by the pictures it sure looks like it is, then the outputs should be square wave, and at least 3.5V peak to peak with no load, usually 4.2-4.5V.
Looking at the scope, having 540mV or 0.54V is no good, having a triangle to near sine wave signal is even less good.
Question, are you sure the scope probe is set at 1X, not 10X ?

Hmm looking at the photos I posted on the forum just now and the encoder has 0500 at the end of the part number. Maybe thats the resolution. Quick google search lists only old parts at high prices!

I was messing around in the back of the orange plug for the spindle encoder trying to understand the pinout, or at least the power wires. The multimeter readings were fussy and I made my first mistake of the build allowing a wire to short. Now the machine powers up in estop with an overload light. Not sure I can or will fix that. 

So instead I took the spindle cooling fan off to expose the encoder and lucky me the pinout is called on the pcb!
 

 

So I soldered up some header pins to bullet connectors from back in the drone racing days. I wanted a much more stable wiring situation after that mistake.
 

I carefully arranged connections to the scope.
 

 

Then I gave the spindle a turn.
 

Im happy to see the encoder doesnt seem damaged!
Im not sure why channel 2 (B+) is so low on voltage. I had to scale the axis a lot more than the others. 
You can see the timing and sinusoidal output of this encoder.   


Any clever suggestions on how to get the resolution without having to count the little bumps on that wheel? Maybe I could rig a tach signal up on the spindle in the scope and compare. That would tell me the belt ratio too which I have no idea what it is.




 

I agree the top switch in this case is an estop switch and has a dog on both sides of the travel. Its already plumbed to the EMX relay for estop.

I am very interested in seeing it. Is it a drop-in replacement for glcanon.py?

Chris,
I think that I have found the problem with the Overlay problem.

In my screen shot above see overlay part appears to be coming from the TOOL NAME:
Class: StatusLabel
Object: lbl_tool_comment

Potential: maxSize Width = 16777215

May want to limit the size of the tool label and let the toolTip show the entire text length of the tool?

I just loaded up a Tool with a long(er) name and one with a short name and you can see that's what is happening.

I'm a noob with QT but, not intimidated. 



 

We Are about to do a big aluminium 4axis carving and the current trajectory generator swaps to no look ahead when it combines 4axis motion with 3axis motion I think. Which is a problem


I think tormach has fixed that.

Does anyone know what the current limit is and can it be fixed easy?


Just been looking at the wonderful work Grotius is doing and wondering if this is possible to fix atb the same time..
Regards

Andrew

The isolated analog voltage output on the 7I96S
is generated by PWM.

De nada, you are welcomed, always.

If the original motors were DC servo, all machines must have what i call "extreme limits", and if those are tripped, the power to the drives gets cut completely.
That is to prevent runout in case the drive output transistors fail in short circuit as that would send the motors at full speed to one side, depending on what side of transistors failed.
If that is the case, i would leave that part of the wiring as is and just add E-stop to it.

From the QtPlasmaC user guide ( Material Converter Section ): "The Fusion 360 tool file must be in the JSON format of Fusion 360."  

The file in the post you referenced is a .csv file.  I suspect that when ashesman attached that, he intended for it to be imported into Fusion360, and not used to spit out a .cfg file for QtPlasmaC.  Further evidence to support this is that he also attached "Plasma_material.cfg", which is an already converted, and valid material file for QtPlasmaC. I think the intent was to give the user a way to import the tool list into Fusion360 so that it matches QtPlasmaC.  

If you use the Plasma_material.cfg file he provided, you will have to rename the file to suit the material file name in your config folder (you should probably back your original up first), since the convention is <machine_name>_material.cfg.

 

Muchas gracias, hasta en este momento me dicen que están descontinuados. La verdad no sé dónde más buscar.