Advanced Search

meister wrote:

i have noticed that you can also generate verilog with litex without soft-core. and that liteeth also supports UDP in hardware. I think it should be possible to build a UDP interface that runs on the Colorlite boards (and others) and can be integrated into RIO.

There are many supported FPGA's and PHY's: github.com/enjoy-digital/liteeth

Would the Tang Primer 20k be a good candidate

i have noticed that you can also generate verilog with litex without soft-core. and that liteeth also supports UDP in hardware. I think it should be possible to build a UDP interface that runs on the Colorlite boards (and others) and can be integrated into RIO.

There are many supported FPGA's and PHY's: github.com/enjoy-digital/liteeth

>In the other RIO gossips; a brand new journey is about to begin!! However and before I
>begin routing this I wanted to poke your expertise and ask what would define a half-
>perfect RIO Motion Control Board. Is there anything fancy that we need on that other
>than the usual SPINDLE + MPG + XYZAB + Ins & Outs?

it always depends on the application,
as a universal board, I would say:

4 step/dir
4 inputs (selectable 24V/5V - Proximity Limit Switch)
1 encoder (for lathe / with differantal inputs)
>=3 inputs (for estop/misc)
>=3 outputs (cooling/spindle)
1 MODUS (vfd-spindle)
1 WS2812b (status display / only one pin needed)
1 PMOD header


I really like these connectors: www.reichelt.de/stiftleiste-2-pol-rm-3-5...rank&OFFSET=16&nbc=1
but it's a matter of taste

i think USB/Seriel is not necessary

the fpga on the tangnano20k has the same housing, if the pinout matches you could also use it !?!?!
not the same

EDIT: and it should work with cheap programmer like the USB-Blaster
 

Looks like you are missing the [PROBE] section in your ini file. For an example ini file see:

github.com/hausen8/EasyProbe/blob/v2.0/m...y_Probe_2.0_demo.ini

Disregard

GitHub download is down and no way to find it anywhere else ? now i have to spend another month to figure out another way to run my VFD, i think instead i will smash this linuxcnc controller with a baseball bat and that will be the best satisfaction this machine ever gave me.

I tried it and it was exactly what I wanted. Thanks a lot

That explanation & diagram makes me think you're right about the pins being a hard mechanical orient system.  The main spindle motor can't resolve quite fine enough, so they use a 'shot-pin' type of indexer.

Good luck tracking down the C-axis stuff!

With a stepper based system you will be limited by the distance moved by one step. In the example you have shown your step scale is 160, ie 160 steps / mm. Therefore 1 step is 0.00625mm

The difference between the commanded and actual position is 0.0063mm (0.00625) or one step. The default deadband within the Remora component is 1/step_scale or 1 step. You can set the deadband to be smaller but then the control loop will hunt as the step resolution never allows the commanded position to be reached.

The pins are strange.  Pneumatic lines to actuators, and proxy sensors if the pins are retracted... fishy.  No idea what they do, other than maybe they're part of an alignment mechanism.

Hypothesis: Perhaps when C-axis is commanded, the main spindle rotates slowly to the encoder index, then one of the pins drops in place (indicating gear alignment with axis servo), then is retracted with the air after the C-axis servo is swung in to engage the bull gear.  That way the gear alignment isn't dependent on the encoder index pulse if the belt is replaced.

Could be the case! I'm thinking that it is mostly just a hard-index system for the C-positioning feature. Maybe it could be used for full C though, will have to look into the type of geometry that is usually used for that kind of worm gear.

Here's what the parts manual has to say about the indexing system we speak of: 



The parts diagrams can be viewed here: 
shop.hardinge.com/medias/sys_master/imag...PLA-0009500-0060.pdf

Strangely, the component list/diagrams that Hardinge offers do not say anything about the original equipment used in the c-axis contouring option, yet it outlines parts for every other optional add-on.



Maybe I'll give Hardinge a call or ask on Practical Machinist. Either way my implementation will have to be something I can pull off and integrate into the LinuxCNC environment. 

 

Gracias, gracias Tommylight, evidentemente me falta aprender, no tuve en cuenta la salida de video del vga, je.
Trataré de bajar la resolución de mi celular, al sacar fotos, porque no me permitió subir las fotos anteriores que quise compartir. Muy amable, en serio!.

Nooooooo!
Your lathe has what seems like a DB9 serial port
You netbook has a DB15 VGA connector for external monitor
Those 2 can not be used together, not the same thing, no wiring, nothing.
As for lathe serial, that also does not work with LinuxCNC, so you will have to open the lathe control box and take some pictures and upload here on the forum.

I deleting everything before the G54 command and edited the Probe_Postgui.hal file to reflect the changes. When I start LinuxCNC, I still get the error: Named Parameter #<_ini[probe]vel_fast> not defined

Is there something that I am missing for declaring the vel_fast variable in the .ini file other than what I copied and pasted from the instructions?


-Sean

Really odd, I did verify that the IRQ coalescing setting worked.
 The only thing I can think of of is that there's a bad character etc
in the interfaces file (you might try using my interfaces file)
This is possible since any errors parsing the file are well hidden

Another possibility is some strange interaction between the
network manager settings and the interfaces file. This could
be tested by deleting the network manager setup for the realtime
connection. I think something may be broken in this interaction
with newer Debian systems as older ones would not allow you to
change settings for an interface that was setup in the interfaces file
(it would be marked as "Unmanaged")

Hey aekhv,
Your github and docs seem to be in a bit of a scramble with your name change on github. Any estimate of when that will get straightened out? Love the project I was able to put together a working configuration for the StepperOnline EV200 pretty easily. Mb2hal just didn't work for this device. Still trying to figure out what their spindle speed register wants, but that is their documentation problem.

You must apply an external voltage (5 to 15 VDC)
between SPINDLE+ and SPINDLE-. This voltage typically
comes from the VFD. (the potentiometer supply) It is best
that this comes from the VFD so the you do not introduce
VFD switching  noise into the rest of the system.

The output voltage on SPINDLE OUT will vary from SPINDLE-
to SPINDLE+ as  the PWM duty cycle varies from 0 to 100%
(0 RPM to full RPM)