hey... I have a quick question on triacs.... need to build an oven controller and looking at triacs.... is a 600v triac marginal on 240vrms... it seems so
well, I suppose it depends
for example, if you have a 600V triac in your junkbox and a higher voltage one is expensive, you might try it and see
I guess thats why they have 700 and 800v versions
FWIW, we use 1600V SCRs and diodes for AC drive rectifiers, with 480V input
so simple scaling would recommend 800V for 240
if you haven't bought anything yet, you'll probably find little price difference between 600 and 800
I have a $2000 kitchen stove that caught fire... thinking of rebuilding with triacs as the original control was crap
so this isn't a short term hobby project - if it works you'll be using it for years
and you don't want to shave pennies
resistive load though, thats is kind of nice
hate to dumpster it..... all the mechanical and electrical is fine... the electronics sucked
I know the feeling
14-30 ohm elements.... couldnt ask for a nicer load
you are thinking phase control? or zero crossing switching?
I guess for a stove zero crossing is fine, and kinder to the power lines
probably zero crossing..... ie turn it on for 1 to 10 out of 10 cycles
ideally you'd use a pdm type pattern, not pwm
for 33%, you'd do 1 on 2 off, not 3 on 6 off
don't forget to do _full_ cycles, not half cycles
thermal log on an oven or stove element is very long... original controll was bang bang with relays
I'm not thinking of the thermal lag
I'm thinking of the line again
if you were to do for example 30 cycles on and 30 off for 50%, you might notice a 1hz flicker on incandesent lamps
but 1 cycle on and one off, never notice
I was playing with classic ladder .... doing entire oven control in ladder!
port to a microcontroller once you have it the way you like it?
not sure if the runtime will fit in a PIC
or the worlds only PC controlled oven?
The embedded compile version was about 50k of i386 code + libraries... could be trimmed a lot I bet
you have to do a temperature control loop, right? set thermostat for 350, control oven based on a feedback device to get 350
yes.. this oven has an RTD sensor 1000ohm to 2000ohm over temp range
just remember to do whole cycles
It was my sisters stove.... so I can work on it as required..... we still have a working one
the utility won't appreciate you drawing stove sized amounts of net DC - the transformers out on the pole will be unhappy
[00:47:13] <LawrenceG> http://cgi.ebay.com/BTA40-700-TRIAC_W0QQitemZ160221460056QQihZ006QQcategoryZ7287QQcmdZViewItemQQ_trksidZp1713.m153.l1262
These are a little hard to drive .... 100ma gate current
thats a notably useless webpage
no specs at all
100mA gate current isn't much
it only needs to be a pulse
nice to mount ... have about 9 elements to control
do you have a URL for a datasheet or anything?
240/14 = 17A RMS
[00:51:10] <LawrenceG> http://www.tranzistoare.ro/datasheets/70/364343_DS.pdf
gonna want at least a 25A part - maybe more - often the specs assume an ice cube for a heatsink
yes... was looking at 40a modules in rd91 case
the insulated case is nice
should be pretty sturdy
a big chunk of heatsink with 9 or so of these mounted with moc opto triac drivers
sounds reasonable - I've no real experiance with triacs, we use SCRs for that kind of thing
and we drive them with pulse transformers
me either... old flashing light organ units for the stereo about 30 years ago!
are you gonna be able to put the sink someplace where it will get cool air? stoves tend to heat up the surroundings
lots of room low in stove... even a small fan is possible
note "Critical rate of rise of on-state current" in the datasheet
with a resistive load and relatively low inductance dI/dT will be kind of hich
self clean cycle will be fun to debug.... 900F if I read the stove schematic correctly
note that the 50A/uS rate is for 200mA of trigger current
exceeding the dI/dT rating will result in shorted triacs
if you are carefull to turn them on right after the voltage crosses zero you should be OK
another reason not to phase control
already had experience with shorted on oven controls..... very bad result on chicken pot pies
a robust circuit would put a snubber across each triac as well
something like 0.1uF and 10ohms
the resistor should be a couple of watts - we use 10W for 480V, so 2.5W for 240
still deciding on whether to trash the stove or rebuild it..... If I do the controls, it will certainly make any future service guys wonder what is going on
yeah, there is always that aspect of it
basically, you are signing up to maintain the stove forever
hey... If I sell the house, it could be my future employment project
that ebay dude is selling the 600V version, right?
yea... I havent seen 800v units on ebay yet
odd, his part number says -700, but the datasheet says it only comes in 600 and 800
to be honest, if you put a snubber on it you'll be fine
still looking for ideas..... there are solid state relays for a good price once and a while
triacs (and SCRs) respond to overvoltage by turning on
in your application, an overvoltage (say from a lightning surge) will turn the heater on for one half cycle
they tend to be random phase unless listed as zero crossing versions
no harm done to triac or oven
I suspect that rolling your own would be cheaper
unless you find quite a deal on SSRs
yea... wondering about a contactor for the main power... would be interesting to take a surge and have every device fuse on
it would take a hell of a strike to make them _stay_ on
wake up with the oven/stove all lit up
I will try not to make it a Jymm project :}
overvoltage will trigger them, but when that happens they will immediately clamp the voltage across themselves and drop the rest of the surge across the elements
a ladder version of oven/stove control would be interesting
but could probably be a lot smaller in dedicated C
the debug feature of ladder is nice
ladder would only work for the high level control
for the actual triac firing, you want to be as close to the zero cross as you can get - a few hundred microseconds or so
true... with a pic, would probably use intr of zero crossing clocking... also, a/d inputs in classic ladder would be nice
emc2 stove control.... need a RR and LF axis
encoder on rotisserie?
thanks for your input.... will look for some 800v devices or some SSR at a good price
jmkasunich: nice to see you on cnczone. :)
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/ (epp.c epp.h): Minor EPP cleanup.
EMC: 03seb 07TRUNK * 10emc2/docs/man/man1/bfload.1: minor improvements to command-line parsing and the manpage
EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: minor improvements to command-line parsing and the manpage
SWPadnos_ is now known as SWPadnos
cradek: do you happen to remember why you put emcCommandWaitDone() at the end of sendMdiCmd() in halui?
I think it was because you wanted to switch back to manual mode after the command completed.. right?
if you don't wait, the mdi gets aborted
I'm thinking how to "fix" this
yeah, if you switch back to manual, then it gets aborted
I'm thinking about staying in mdi
and only changing back to manual after the command completed
actually changing back to the mode it was previously in
I don't really care for the whole scheme
yeah, me neither.. but it needs to be fixed
having abort & estop & co disabled during the MDI is a problem imo
maybe every halui control, when invoked, should check and set the mode so it works
so if you press jog during a MDI command, it should abort and switch to manual?
I don't know
maybe you should do the fix you said
This is the 8.04 box
or still live?
The package update was about 200 meg
and it failed a time or two
you'll get that a couple more times before release
But it's going and looking pretty good.
What are the issues around MDI mode?
that's good news
cradek: I think a proper fix would involve the runlevels JMK mentioned
rayh: there's a small problem in halui
if you define MDI commands in the ini (to be triggered by a button), they block other stuff while they execute
well.. if you want to push abort or estop.. I'd say they should get through
Does the NML still have the three levels of wait?
I think so
it's not a philosophical issue, just a coding problem imo
(e.g. bug in halui)
I remember having to twiddle these to get it to see stuff during a move.
as it is now halui simply waits for the mdi command to finish
which means it doesn't update it's hal pins in that time.. which makes it immune to any triggering from the outside
I know "wait done" hangs everything until the end of a command.
yeah, and that's not good
I'll change it to "wait sent" and switch back to mode-manual lateron
I'd rather see that than it dropping out of mdi the instant something else happens.
something else = user pushing some button
but I think this needs to be something for the integrator to decide
This is a case where sets of integrator parameters would be useful.
I don't know how we'd do that in the code.
Does halui expose any parameters now?
spose I could look!
Doesn't look like it does.
I think I made them all pins
I don't see a point in having parameters
This kinda edges back into the old Task planner stuff.
It would be nice if we could set these sorts of parameters system wide and have the guis all honor the same set.
Latency-test did not want to run on 8.04.
that's because pyvcp doesn't run
they changed some python-xml stuff, 2.2.5 will have a workaround
Ah. That's it.
you can run the rtai native one
I'm seeing some jerky motion soon after I start running the first part.
I don't see it in halscope, the stepper pulses are in there. Just the axis display.
hmm.. display issue?
Might be the python thing again.
I think it's vesa
It does not seem to do it with the mini interface. Let me go back and test with axis again.
Still there. I'm using cds.ngc and when it starts it jerks several times during the first few moves then seems to settle down.
at the beginning of the program, AXIS is fighting with task for userland cpu time. at the start of a run, task is busy queueing up segments as fast as it can
vesa video might make it a little more apparent than usual
It looks like it's doing it during line moves. It seems to go into the line just a bit and then stops and waits until the motion has gotten to the end of the line. Then the tool jumps to the end, rounds the corner or whatever and pauses until the next corner. It is good on arc moves.
alex_joni: were you able to disable desktop effects by default? I hear they really messed with the operation of real opengl programs
It does not do it all the time.
Effects are off here.
cradek: they don't get turned on for the most cards
I should probably get a machine set up with 8.04...
nvidia & ati only get it with the properietary driver, which isn't installed
and the only one which has the desktop effects enabled is i8xx
The position display does the same thing.
Waits while the tool is stuck. But the motion is continuous.
rayh: maybe watch top while it's happening. I bet task is taking all the cpu
This is a stock stepper and a rather fast box.
I saw a lot of arguments in #ubuntu-kernel about what scheduler options should be turned on for this kernel. I hope whatever choice they settled on doesn't work badly for us compared to dapper
(I didn't follow/understand the arguments)
xorg, axis, milltask in that order
hm, xorg first (opengl rendering)
milltask takes about .7
axis and xorg are running about 15
cradek: we can always change the scheduler option for our kernel
it would be interesting to run the same thing, also with vesa video driver, with dapper booted. should be able to do it booted live.
I was wondering about nice priority
whee.. this seems to work how I would expect it to..
let me look at the other box.
anyone wants to test? (halui change I mean)
My 6.06 is vesa and I've not seen it there.
But will run a test right now.
I do see the refresh as very short jumps but there is none of the big stops and jumps.
That is on a slow box 1.2 via chip.
rayh: I was hoping you could try it on the same hardware, to compare the two releases/kernels
I had 6.06 on this box. It was there since you built the 6.06 cd. I'd think that I'd have seen it.
I don't use axis much but I did experiment with it and the jerking would have jumped out at me.
hmm.. wtf.. when I open cds.ngc, the display doesn't change
I do have an exact same box next to it. I'll see if I can find a 6.06 cd and try running there.
RuntimeError: interp_error > 0 but no Python exception set
I've got 2.2.1. I'll try it on this box and report back.
rayh: in some previous version I did mess with the nice level of AXIS. But if you are running the same version on both that can't be it.
cradek, jepler: any idea about this? http://pastebin.ca/990902
sounds like AXIS' interpreter is failing on that file
try loading other files? other files with errors in them?
other files seem fine (from nc_files)
try files with errors
jas, trying to commit the fix on halui
Works like it should on 6.06. Just floats along.
rayh: is it the same emc2 version? also vesa driver?
same configuration (especially base period)?
EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: fix #1929461 - halui stops reading inputs during a MDI, also add uvw position info
cradek: I get an AXIS popup on loading the file with an error
G-Code error in 3D_Chips.ngs: Near line 11 of ...
fascinating. it's emc 2.2.1 and it says it's using an sis driver.
cradek: well.. it obviously needs testing..
I don't see any error when I load it.
I'm on TRUNK
Let me go back to 8.08 and change to the sis display driver and see if that fixes my problem.
cradek: I think it's failing on n0080 G43 H1 g20
That messed up more than a few things.
axis does not pause as often but it still jumps quite a bit more than I've seen with other systems.
cradek: it's something that's related to G43 H1, TLO
Now that I've got the whole thing working with the sis driver, I think it seems to be working fine.
so it probably was a performance issue
rayh: I didn't like the bird either, when I first installed hardy
My granddaughter thought it was awesome.
Funny 7.10 identifies the same driver as via.
must be a pretty generic display chip to let so many different drivers run it.
maybe no-one knows what it really is :D
anyone else think Intrepid Ibex is an odd name?
Sounds like they may not be taking there medication.
Top tells me the same order xorg, axis, milltask but xorg is running about 30, axis about 20, and milltask about the same.
cradek thanks for the nudge about drivers.
rayh_ is now known as rayh