gene heskett wrote:
On Monday, April 16, 2012 12:05:22 AM Jon Elson did opine:
It was described earlier that the charge pump input to the G540 is
capacitively
coupled, and apparently has a large coupling cap. If it is driving the
base of a
BJT with the cap, that would require a pretty
Kirk Wallace wrote:
Most of the components on the G540 are SMT and too small to have
markings, so I could only guess about what they are. I have some close
up pictures of the area in question, but my camera's cable has woken up
and run off somewhere. I'll post the pictures when I get this
Terry Christophersen wrote:
Hi all,
I have a Hardinge HNC that I am toying with the idea of retrofitting.I know
there is
a few on this list that have done so,I would like to know the amp/motor
combos that are
in use.I have one that I put a Centroid on a few years ago but I dont have
the
andy pugh wrote:
On 17 April 2012 01:48, Ian McMahon facetious@gmail.com wrote:
I'm using the original motors and original amps with good success.
Indeed, there seems no reason to ditch the amps, you just need a good
EMC-compatible analog output board.
Umm, if these are GE
Dave wrote:
True, but even little Nema 23 steppers have little usable torque beyond
800 rpm unless you go with a high voltage stepper drive (which the G540
is not).
Larger Nema 34 steppers are pretty useless beyond 600 rpm or so.
I used to demo my mini-mill with Gecko 201A drivers and
Terry Christophersen wrote:
That answers my question.
That looks like a lot of files to get your turret to work.
What is the board next to the DAC ?
I was under the understanding that the PWM main board read the encoders
He is using a hand-made board to convert differential encoder signals
Dave wrote:
It is just a little overwhelming what can be done with these ARM MCUs.
Yes, I'm using the Beagle Board in some projects. One of them receives
TCP packets
and sets a 32-in 8-out signal multiplexer in a location that is
sometimes inaccessible
due to radiation. It is a totally
Viesturs Lācis wrote:
I think that this issue is fighting the consequence instead of fixing
the real cause.
People want to change the look ahead behavior, but I am completely
sure that fixing the cause - getting normal g-code is much easier. At
least for those things that my machines are
Viesturs Lācis wrote:
2012/4/19 Jon Elson el...@pico-systems.com:
But, LinuxCNC does not do arbitrary arcs, but only arcs in one of the three
orthogonal planes.
How hard would it be to add that? It would require 3 coordinates for
each of start, end and center point.
The first
Chris Radek wrote:
The correct solution is probably to specify the plane's normal vector.
While it's entirely possible to do, I doubt anyone would ever use this
feature if someone did the work to implement it.
Yup, messy. Maybe NURBS is really the way to go, it seems to solve several
of
Kenneth Lerman wrote:
Others have stated that arcs must be in one of three orthogonal planes.
Since linuxcnc can do helices, that isn't precisely true.
A helix is a special case, where an arc in one of the 3 defined planes
adds a
coordinated linear movement of one axis not involved in the
Viesturs Lācis wrote:
Is there a way to create a filter that would convert those small, tiny
G1s into a 3D Nurbs lines?
snip
The only thing I do not get, is how to do the reverse math - describe
a line, if (a lot of) points on it are provided. It does not seem to
be problem finding formulas
andy pugh wrote:
As I said earlier, I don't think this is a Lookahead problem, it is
a must be able to stop inside the next code block problem.
And I am not convinced that being able to stop the machine within the
next code block is necessarily a sensible requirement.
Exactly! It is a
Erik Christiansen wrote:
Curve fitting to an arbitrary bunch of points is an approximate art,
AIUI, with tolerance calculation at all points probably taking a bit of
time. Admittedly, I don't know whether nurbs make that faster/slower or
easier/harder to achieve algorithmically. But it does
Stuart Stevenson wrote:
Doesn't even G02/G03 result in a series of very small linear moves sent to
the servo motors? Wouldn't a NURB conversion do the same thing
Yes, in a way. But, the G02/G03 is known to be a single move, so there
is no velocity
change until the end of that move. NURBS
Viesturs Lācis wrote:
I also agree that separate filter would be better. Because the problem
is solely in the g-code, so the filter to sort out the code is needed.
With proper code the existing LinuxCNC can completely handle the job.
Not completely. Some very correct G-code cannot be fixed
Thomas Powderly wrote:
here's how one group worked with the fast turn around at edge of work
the machine tool was like the emc2-bipod and the software built
huge arcs into the endmotions to keep velocity up and dampen the bipod swing
Certainly fixing this in the CAM is the best approach,
Kenneth Lerman wrote:
It seems too simple. What am I missing?
It needs to look ahead an arbitrary number of blocks to see if a big
slowdown
is required some time ahead. When this stuff is interpreted, and that big
slowdown is spotted, you have to go backwards through the blocks
some amount
Viesturs Lācis wrote:
2012/4/21 Jon Elson el...@pico-systems.com:
Stuart Stevenson wrote:
Would a read ahead of 1000 lines be more time consuming than the NURB
calculation?
A modest NURBS surface could be scanned pretty quickly to find the sharp
edges,
if any. 1000 block
Viesturs Lācis wrote:
I just resoldered the same transistor for the base-collector-emitter
pinout (collector in the middle, not base as I tried previously) and
tested and it works.
Great. If it has the same part number, it SHOULD have the same pinout!
Any maker who does it differently
gene heskett wrote:
But then which of the
other two are emitter and collector?
This can usually be done with a DVM with diode test. Connect the
meter between C and E, and then connect a resistor, like 22K Ohm
between base and the suspected collector. Note the meter reading.
If it is about
Viesturs Lācis wrote:
What I see the big issue for solving this in trajectory planner or
whatever _inside_ LinuxCNC is that I do not see, how to determine by
some hard facts, what is the best way to determine the lookup amount.
The number of blocks you need to look ahead is variable. The
Erik Christiansen wrote:
Jon, there's probably no need to do this backwards. Look-ahead only
needs to be simple look-ahead, nothing more, AIUI. The current velocity
(feedrate) is known, and the stopping distance for the machine at that
velocity is fixed.
So, by summing immediately upcoming
Michael Haberler wrote:
I would also think the effort is considerable, and would not necessarily
recommend grafting this onto the current code. But then it's time to start
collecting ideas for Linuxcnc3.
Wow, a lot of details. Well, certainly this is not something to be
patched-on in a
Eric Johnson wrote:
Hi all,
I have a servo motor axis configured angular with a relatively low
resolution encoder / gear ratio. One revolution of the shaft is 19600
counts, or 54. counts per degree. I was having a very difficult time
tuning it at 54 counts per degree, so I set the
Kent A. Reed wrote:
Question to y'all. Do these electronic techniques deliver the goods?
I can tell you that the Gecko 201A from way back around 2000 were quite
awesome.
I have fooled around with steppers for some time, and the G201 was the first
drive I would even consider for a CNC
Viesturs Lācis wrote:
2012/5/1 John Thornton bjt...@gmail.com:
The G203v's that I use on my plasma cutter are smooth as silk and when
you adjust the morphing pot you can really tell the difference when it
is adjusted correctly.
Hmm, I put 6 G203v drives in the welding robot, but
Peter wrote:
Jon,
It doesn't switch from 1/10 to full-step, it morphs. It's not done
with clocks and dividers, its done more in the analog side. That's the
difference that Mariss adds. Anyone can built a microstepping drive. There
are scores of application notes and open source designs.
Peter Homann wrote:
Better to hear from Mariss himself.
snip
Simple drives persist in microstepping anyway above this speed. This means
they still try to make the motor phase currents sine and cosine past this
speed. A little problem with that and it's called 'area under the curve'. The
Kirk Wallace wrote:
I suspect the magic is in the Xilinx chip programming, so we'll probably
never know what the magic is.
The G201A and some other drives from years ago used CD4000 CMOS chips and
had all this. Those drives could be deciphered fairly easily.
I'd like to play with a couple
Peter Homann wrote:
Jon,
IIRC correctly the pre CPLD drives did not have full step morphing. Also the
new drives have a much improved recirculation sequencing. This means that
heat
sinking requirements for the drives are greatly reduced.
Right, I agree about the recirculation change,
gene heskett wrote:
Greetings;
As I read the hal manuals getting started section, where the keywords
loadrt, setp, addf, and net are defined, I didn't understand at first that
arg[3], arg[4] arg[5] etc of a net commend can be repeated to add sending
something from arg[2] to more than one
jeshua wrote:
I am looking at the data sheet for that chip:
http://www.datasheetarchive.com/OX16PCI952-datasheet.html#
It states on page 52:
To use the Enhanced Parallel Port (‘EPP’) mode, the mode
field of the Extended Control Register (ECR[7:5]) must be
set to ‘100’ using the
gene heskett wrote:
Thanks to all who helped, I cut another thread this evening, wrong of
course but at least I now know why it was wrong. Hopefully the next one
will be right. ;-)
Progress comes in small steps, but as long as each step moves in the right
direction, that is good!
Jon
Jeshua Lacock wrote:
Actually it looks like the UARTs show up as a separate device:
08:00.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950
UART) function 0 (Disabled) (rev 01) (prog-if 06)
Subsystem: Oxford Semiconductor Ltd Device
Flags: medium devsel,
Dave wrote:
Jon,
Why would they do that? So it is stuck in SPP mode?
Is this an attempt to idiot proof the card so it works for most people
out of the box?
Yes, very likely. Perhaps Windows drivers reset this with some of the
PCI setup
registers. I suspect there is a setup utility,
Kirk Wallace wrote:
I believe the EEPROM programs the chip pin-out or rather tells the PCI
chip what product it's on, and probably is not meant to be changed after
the chip is soldered to a board. Also the datasheet seems to indicate
that the chip follows the Microsoft interface spec.:
jeshua wrote:
OK, in this badly trashed document (at least on my browser) :
http://www.soiseek.com/OXFORD/OX16PCI954-TQC60-A1/56.htm
It mentions there is a Windows utility to reprogram the options EEPROM
available from Oxford Semi. No link is provided.
Page 72 of that doc has some email
gene heskett wrote:
On Sunday, May 06, 2012 02:33:08 PM Jon Elson did opine:
What is the best practice to establish the X zero on a lathe? I am making
a test cut, measuring it and dividing that by half to enter in a Touch Off.
If you have a quick-change toolpost, you should be able
Jeshua Lacock wrote:
I have never written to an EEPROM before, so I think I would rather order
another card to spare the expense of small pci card.
You don't have to know what you are doing, if you can get the config
utility for
that card, you just set the options you want and hit go.
The
Ed wrote:
I'm finally getting up my CHNC wired up a piece at a time and am
wondering which way to go on the Ubu. version?
I have played with 8.04 and it seems to be faster than 10.04, probably
because of bloat. The install is in a 2.6Gh machine running Pico Systems
hardware so I don't
gene heskett wrote:
On Sunday, May 06, 2012 09:15:18 PM Jon Elson did opine:
you should be able to set up X and
Z offsets for each tool in the tool table.
That would require I get at least 3 or 4 more QC toolholders. But then I
am reminded that the QC post must be rotated
Jeshua Lacock wrote:
BTW: apparently my current card is PCI, not PCI-e:
http://www.amazon.com/gp/product/B000MY45WS/ref=oh_details_o00_s00_i03
Somehow I got the idea from one of the lspci reports that your board was
pci-e.
The Startech boards were reported to work by some other people in
gene heskett wrote:
On Monday, May 07, 2012 10:56:31 AM gene heskett did opine:
No - My tool 1 is my reference and touch off tool, it has offsets of
0, 0, all other tools are referenced to that - it's a CNMG type
An acronym I'm not familiar with, but I expect google works ...
gene heskett wrote:
There is an echo in here. Maybe John and I are alone, but I think far fewer
homing and touch off mistakes, where a previously established setting was
in-advertantly foobared, is caused by the auto coupling between the last
axis moved and these two functions. I have
Jeshua Lacock wrote:
I just installed my new Siig card and I am not having much better luck so
far. Launching LinuxCNC did not switch it to EPP mode.
Here is what lspci reveals:
08:00.0 Parallel controller: Oxford Semiconductor Ltd OX9162 Mode 0 (parallel
port) (prog-if 03)
Jeshua Lacock wrote:
On May 8, 2012, at 8:33 PM, Jon Elson wrote:
How do you know it did not go to
EPP mode?
I guess I don't know for sure. Your 'univstepdiag' program gives me a
'Segmentation fault' error and the output from dmesg after attempting to
start LinuxCNC
Jeshua Lacock wrote:
So, I noticed when linuxcnc fails to launch, it states this in the Kernel
message information:
PPMC: ERROR: no boards found on bus 0, port 0378.
I thought that was curious since I have never specified the port in the linux
config files that I knew of. Is there
Scott Hasse wrote:
I presume many of you have seen the hype on the Raspberry Pi. Am I correct
in thinking that getting LinuxCNC to run on one of those would require an
arm-specific RTAI and drivers for the device-specific I/O? Has anyone else
given any thought to this potentially disruptive
Kent A. Reed wrote:
As for the ARM-specific real-time Linux that definitely is required, Jon
has been waiting for several years for RT-Linux to be ported
satisfactorily to the BeagleBoard.
Slight error, it is RTAI that is not yet available on the Beagle. I
believe RT-Preempt
may be
Eric Keller wrote:
At least the ARM boards have the potential for replacing the PC, but a
Beagleboard is more expensive than a much more capable Atom.
This may not be quite true. The Beagle has integrated memory, and can
use very cheap
(4G, 8G) SD cards for hard drive. The Atom needs to have
k...@gmail.com wrote:
There is a bit of talk on some machine shop forums, arguments perhaps, that
retrofitting a machine is a waste of time.
And that it's time and money well spent to just buy a good used
machine and move on with making money with it.
Any comments on this from the list?
andy pugh wrote:
Are you talking about retrofitting LinuxCNC to a used CNC machine here?
Many old CNC machines have good iron but broken/old/rubbish
controllers. A controller-only retrofit of those machines can be
fairly quick and fairly cheap.
One comment. Many machines from perhaps 10
gene heskett wrote:
The onboard connector is standard 24-pin ATX power supply plug.
There are users that have pico-PSU for these boards, but I use normal,
standard 300W or 500W ATX PSU so that I have 5V and 12V dc source for
switches and other stuff as well.
If you use a smaller power
andy pugh wrote:
On 13 May 2012 22:43, charles green xxzzb...@yahoo.com wrote:
has anyone ever heard of a ball worm?
I have seen one developed by a college urology department, which is
slightly scary.
Yes, before rack and pinion steering, cars used Armstrong steering gear,
dave wrote:
Hi all,
Sometime ago I bought a D510MO to replace my aging 1.2 GHz Duron. I'm
finally frustrated enough with the present cpu, etc. to actually
upgrade. ;-)
http://www.logicsupply.com/categories/power_supplies/dc_converters?gclid=COeJt5m4_q8CFSIHRQodoQGGHA
I've been looking at
dave wrote:
Hi all,
Sometime ago I bought a D510MO to replace my aging 1.2 GHz Duron. I'm
finally frustrated enough with the present cpu, etc. to actually
upgrade. ;-)
Oh, and of course, you can buy a bunch of micro-ITX power supplies for
these 7 square CPUs. The lower-powered ones are
Dave wrote:
There were/are some manufacturers of hydraulic cylinder driven milling
machines.
I forget who made them in the USA - Cincinnati Milacron perhaps.
Cincinnatti made the machine, Moog made the control. The control was
all pneumatic,
no interpolation, not even linear. It used
Stuart Stevenson wrote:
I had two MHP machines. MHP = M(oog) H(ydra) P(oint)
They ran gcode just like any NC/CNC machine. Each linear axis had two
cylinders opposing one another. A hydraulic servo valve released pressure
from one or another cylinder to allow the table to move away from the
Eric H. Johnson wrote:
Hi all,
Oops again, just a typo on my part. I was using coordinate system 3, but
erroneously referred to it is 2. So the P values are being used correctly
and the problem remains.
Why are you working in the machine coordinate system? I never do that,
it is for
Eric H. Johnson wrote:
Jon,
I am using the coordinate systems as a means of getting multiple tools
offset in X and Y from each other so they can land on top of each other.
IOW, do a pass with one tool, then apply the offsets of another tool but
otherwise follow the same tool path.
I thought
Eric H. Johnson wrote:
Andy,
You _could_ do that with tool offsets in the tool table. (I think).
All tools have spaces for offsets in XYZUVW.
Are you talking about tool.tbl in the config directory? It looks to me like
you can only set tool length
and diameter. Am I missing
andy pugh wrote:
On 19 May 2012 02:40, Jon Elson el...@pico-systems.com wrote:
Anyway, the G10 L2 Px adds an offset from the CURRENT machine position,
Are you sure about that? That isn't what the docs say. G10 L2
shouldn't consider the current position at all, it should simply
Erik Christiansen wrote:
Um ... that's always been my problem, when reading the older
documentation. i.e. where the machine is NOW w.r.t. what? Yes, touch
off from the workpiece, and those other references become moot.
It scares me that coordinate offsets could be cumulative. Coordinate
Terry Christophersen wrote:
LMC or LNC sounds good to m
Logical Microcomputer Company made Unix-based computers using the
Nat Semi 32016 CPU back in the late 80's. The system was a dog, for
reasons I don't quite understand, maybe rotten compilers. I'm pretty
sure they have been out of business
Jeshua Lacock wrote:
Greetings,
I seem to have the damping turned all the way up on my Gecko 320, but it is
still underdamped.
Is it possible to increase damping with the PID settings (I am using the Pico
Systems USC board)?
Would gearing down my drive further help with damping if I it
Jeshua Lacock wrote:
Well lets just say the only thing that I am sure about is the drive is
under-damped.
;)
Tuning is proving to be insanely difficult for me, I guess mostly because I
don't really have much of a clue what I am doing. It is also kind of scary
because if I turn a POT on
dave wrote:
The 32016 was a good design as far as I could tell. Orthogonal
instruction set, 8 sets of registers, etc. I understand that National
simply didn't give much support. Most of the boards were VME bus.
The chip seemed to get used more in Europe than here.
National Semi never was
andy pugh wrote:
On 20 May 2012 17:40, Rafael Skodlar ra...@linwin.com wrote:
I wonder what kind of power and data cables would you recommend for use
in X-Y-Z CNC about 1.2mx1m size?
The size of the machine is not the most relevant thing, though a
bigger machine will might need
Jeshua Lacock wrote:
Actually, I really have only been using open-loop mode.
Since we had confusion here, open loop means LinuxCNC does not see movement
when you move the motors.
I am a little confused however because changing the PID settings still seems
to affect the drive.
Yes, even
Przemek Klosowski wrote:
Not to mention the fact that they acquired a reputation for
long-unfixed bugs and difficult interfacing
http://www.os.4uj.org/16032.htm. Still, it was a nice design and a
pity that NS didn't succeed in the effort to match its excellent
analog products with a digital
Rafael Skodlar wrote:
On 05/20/2012 12:12 PM, Dave wrote:
On 5/20/2012 12:40 PM, Rafael Skodlar wrote:
I wonder what kind of power and data cables would you recommend for use
in X-Y-Z CNC about 1.2mx1m size? Besides power, it's not clear to me how
many data lines for sensors,
Jeshua Lacock wrote:
Putting these numbers in immediately made the drive stable - even in closed
loop which is now what I am tuning.
I was able to get the P up to 150. I can add some D, but it seems that it
only makes the drive more jittery without decreasing the error.
Well, then lower
Rafael Skodlar wrote:
Thank you very much for detailed advice to all of you that responded to
my question. I received enough material to spend a few evenings doing my
homework. It's much easier to start knowing what others have tried and
what works in different circumstances.
Using
Matt Shaver wrote:
I would also be interested in hearing from any people with experience
in Fortran who would be interested in helping port this code to the
Linux platform. If you could indicate your level of Fortran experience
and any reasons for your interest in this code, that would be
Roland Jollivet wrote:
Does this mean you can use lower resolution encoders on the motor, or
should they be similar?
If you had 1um resolution on the fixed linear scale, what linear resolution
should the rotary encoder yield?
It would probably be best if the rotary encoders had quite a
Dave wrote:
That board is considerable cheaper than a D525 and a wide input range
power supply.
The AC-input supplies for these micro-ITX boards are quite cheap. You
can get
a mini case with power supply and front panel buttons and indicators for
less than $50. The DC-input supplies are
dave wrote:
I'm hoping we can keep the entire thing in FORTRAN just because it is
supposed to work there.
OK, what is the status of open-source FORTRAN compilers? I know there
were some
problems with the old f77 compiler that was part of GNU. How about gdb
support,
and maybe electric fence?
Dave Caroline wrote:
I have spent a while trying to get the APT360 version 64bit compliant
and have to agree about common block missmatch.
This code does have unmatched common blocks in differing phases of the code
which Im not sure f2c and gcc get right.
The only solution is to make the
Jeshua Lacock wrote:
Greetings,
I turned on the power to my system today and my 180 pound gantry shot full
speed crashing hard into the end of my table.
I was a stumped at first as the last time I used it everything was stable. It
turns out that I had a loose connection to the encoder.
Jeshua Lacock wrote:
It felt like I wanted to get P set as high as I could. Is that correct? Or as
long as P is high enough to command the machine to move is that adequate?
You want the P as high as you can get it while still having stable
response. Low P will
lead to sloppy positioning,
Roland Jollivet wrote:
Thanks. And a curved ball;
Does the rotary encoder really have to be in sync with the linear scale?
I'm thinking of a small encoder that is geared up, off the motor shaft
(tenshioned/no backlash)
No, it really can't be. You would never be able to sync up a linear
Lester Caine wrote:
Jeshua Lacock wrote:
I am guessing there is not an easy way to detect this condition, but I
wanted to see if anyone else has any thoughts on the subject.
I would have thought that if the motor turned more than 1/2 a turn or so but
the
encoder feed produced
Jeshua Lacock wrote:
Jon, can your power switch and braking module (and/or the brake on the Gecko
Interface) be used like for something like this?
This is EXACTLY the condition it is designed for, BUT, it needs to know
that a problem
exists. You should have hit the E-stop button when the
On May 23, 2012, at 2:01 AM, Claude Froidevaux wrote:
1) make a hal check, that disable drive if more than 5-10 consecutive
sample period with maximum drive output without any encoder change
This won't work in Jeshua's setup. When coming out of E-stop, there is
no commanded
andy pugh wrote:
On 23 May 2012 07:08, Jeshua Lacock jes...@3dtopo.com wrote:
I am guessing there is not an easy way to detect this condition,
It should be possible to check if your PID is saturated for more than
a second or so.
But, this still doesn't detect a servo runaway
andy pugh wrote:
On 23 May 2012 06:35, Claude Zervas cla...@utlco.com wrote:
Just wondering if someone might know why LinuxCNC interprets the G04
dwell command parameter as seconds instead of milliseconds?
The glib answer is because that is how the programmer coded it. I
suspect
Kent A. Reed wrote:
On 5/23/2012 5:53 AM, andy pugh wrote:
Unfortunately the
G-code standard is not very standard.
Every information-representation standard I ever met was encumbered with
exceptions, variants, special cases. After all, they're written by
committees (on some of
Peter C. Wallace wrote:
I think the saturated PID output is a fairly good way to detect this
condition
and certainly would have workied in this circumstance.
No, I believe not. This happened probably before the LinuxCNC PID loop
was even
turned on. It was purely the G320 coming active and
Peter C. Wallace wrote:
Which is a good illustration of the limitations of step/dir servos since
LinuxCNC can't see whats happening in the drive, which rules out a lot of
hardware fault mitigation strategies.
Well, really, detecting all possible cases of a failed encoder is not
that
John Kasunich wrote:
I guess I must have missed something. I never saw him say he was using
drives with step/dir inputs.
Gecko G320
If that is the case, then he probably
isn't
using PID loops at all - the drives are closing the position loop and
LinuxCNC is treating them like
Kent A. Reed wrote:
Of course all roads lead to LinuxCNC, but is there some reason one
couldn't/wouldn't start with one of the many microcontroller chips or
even ARM-based SoCs and build a separate watchdog for the purpose of
detecting and stopping servo runaway in its tracks? It would
Viesturs Lācis wrote:
2012/5/23 Dave e...@dc9.tzo.com:
Probably the wrong page...
http://www.logicsupply.com/categories/mainboards/intel_atom
I like their description for D2700MUD board. Especially last sentence:
2.13 GHz dual core Intel Atom D2700 (Cedar Trail) fanless processor
Yishin Li wrote:
I see. One more question: Pico-Systems' Universal PWM Controller also has
a FPGA on it. How does its firmware/source-code get distributed?
It is on an SST serial EEPROM on the board. I have a circuit that
allows these to be read
by the FPGA (newer Xilinx FPGAs know
Kent A. Reed wrote:
Well, shoot, can't we make it more complicated? This sounds like a Don
Lancaster solution straight out of the pages of Popular Electronics :-)
In the good old days I could think this way but 40 years of digital
electronics have fried my brain.
Yeah, this is not the
Jeshua Lacock wrote:
Would you be interested in designing and building me a few? Just let me know
what it might cost (on or off list is fine with me).
Well, I guess I could do that. I'll have to look up some parts and see how
simple I could get it. I have a Gecko 320 here for testing the
Kent A. Reed wrote:
I have no stomach for trying to recreate my
1970-vintage mastery of Assembler/360.
Don't forget to save R14 before calling a subroutine or you get an infinite
loop when you BR 14. Ohhh, so glad I don't have to write code for
360's anymore! If we added up all the
John Thornton wrote:
I've built several rotary phase converters using plans from the web but
they all seem to stop at adding a few caps to balance the voltage and
the auto start circuit with the potential relay.
Have you ever peeked into your commercial unit to see what else is there?
Kirk Wallace wrote:
I would think
an Aurdino like processor could measure the voltage and current on each
phase and switch capacitors in or out as needed.
This is a lot harder than it sounds. Connecting two capacitors with
different
voltages on them together leads to nearly infinite
Ralph Stirling wrote:
I'm surprised nobody has mentioned the solution to this problem
I always see over at Practical Machinist CNC forum. The preferred
solution to creating 3 phase power over there is the PhasePerfect
electronic converters. I've never personally used one, but they
look like
201 - 300 of 4201 matches
Mail list logo
