Now I see the relationship of script to action , even how you added a function
to the loop - COOL !
I'll have to check R8/R9 Q9 D5 , as "ACFailureAlarm" is checking the board
trafo's ac. Maybe bridging the secondaries on the little trafo changed something
and the alarm is just doing it's job ? It was sensing an unloaded secondary ,
now it's quite loaded down with the "hungry" LM7812.
OS
Mine's been running without a hitch like this for a few weeks now. I've had an amp playing all morning with mine but no inrush relay connected right now.
But - if your running V5 script , the "acfailure" line is off (commented).
thermal is also commented - but I already changed this in V5 to test mje340's
with a bic lighter - this works !
Nothing at all wrong with parallel secondaries , I ran mine overnight with V5 - cool little trafo in a hot house
- all 4 relays sucking the power. (7812 is cool, too).
OS
I'll check mine out later. I've tested thermal operation. It actuated when I had a slewmaster oscillate and pop an output device without overcurrent sensing connected(Q109 seems to be the first one to fail is such case so maybe that would be the one to attach the sensor to ). It was working. I thought I had tested AC failure operation as well.
BTW, I have "unbricked" FTDI chips at my three "counterfeit" controllers, bricked earlier with an evil new driver. So if someone needs assistance - let me know
I wonder why I haven't had any problems. Mine hooked right up. Maybe an outdated driver?
The driver I use now - 2.8.14
The latest version, which is still ok - 2.10.something
2.11 and 2.12 - the killing ones
P.S. Sometimes windows tries to attach 2.12.something driver automatically, so now I check the driver version in the device manager every time I connect the new controller
For already "known" ones the correct version is assigned...
The latest version, which is still ok - 2.10.something
2.11 and 2.12 - the killing ones
P.S. Sometimes windows tries to attach 2.12.something driver automatically, so now I check the driver version in the device manager every time I connect the new controller
For already "known" ones the correct version is assigned...
Last edited:
Time to troubleshoot , even as the AC detect is one of the more minor protections.
first is to measure the components in the circuit - all those barely readable asian color
codes .
I see something I did ... put 270K in for R8/9 instead of 220K. Maybe not enough
to swing Q9 with my reduced bridged trafo secondary V . I'll try for 150-180K here
just to make sure. D5 cathode would be the live test point to determine operation.
Speaking of "bricked" - guess what - the Mouser arduino works but now won't !!
talk through the ftdi driver - "bricked" ... it worked before. Argggg ! I hate being
screwed with a "political driver" .
Val , could you elaborate on the "unbricking" , I researched and mentioned it but
never actually had a bricked one until now (I think) ?
OS
first is to measure the components in the circuit - all those barely readable asian color
codes
.I see something I did ... put 270K in for R8/9 instead of 220K. Maybe not enough
to swing Q9 with my reduced bridged trafo secondary V . I'll try for 150-180K here
just to make sure. D5 cathode would be the live test point to determine operation.
Speaking of "bricked" - guess what - the Mouser arduino works but now won't !!
talk through the ftdi driver - "bricked" ... it worked before. Argggg ! I hate being
screwed with a "political driver"
. Val , could you elaborate on the "unbricking" , I researched and mentioned it but
never actually had a bricked one until now (I think) ?
OS
I'm using the old one (ch340 driver) now - I'm not screwed. Tried all that.
The new mouser one has the V5 script - a good reference (but i think it be bricked).
PS - If Val don't respond I'll find the reg key (or whatever).. after I fix the AC issue.
OS
@os:
Link to the procedure for unbricking device in Windows 7:
https://www.youtube.com/watch?v=RZH_qGautqM
I haven't tried this, but it uses the "Mprog 3.5" utility from FTDI's web site and takes a couple of minutes.
Link to the procedure for unbricking device in Windows 7:
https://www.youtube.com/watch?v=RZH_qGautqM
I haven't tried this, but it uses the "Mprog 3.5" utility from FTDI's web site and takes a couple of minutes.
Last edited:
YES ...470K - 1meg for R8 allows Q9 to stay high with the lower voltage AC
of the bridged secondary.
I noticed below 330k
for R8 a relay switching will sometimes trigger the arduino. AC voltage fluctuation
on the little trafo does this.
A larger C1 would
eliminate this "false triggering" - >.5u .
"ACFailureAlarm" is now uncommented. A quick interrupt to the ac will shut all
relays down. All linear "bugs" now gone - whewww !
PS - but .... a longer ac interrupt will recycle the loop ?? I suppose this is the
concept ?
Currentflow , thanks for the link. I will try it.
OS
Back again
You're right - quick interrupt, or some sort of quick bounce of ac will shut the amp down, indicating AS Failure. Longer interrupt will lead to Arduino restart, initiating the soft-start sequence again.
With regards to unbricking.
First of all - see the driver version you've got now.
Device manager, right-click on your controller port, "Properties" -> Driver tab.
If it shows 2.12.0.0 - that's the latest "killing" one.
On the Details tab select "Hardware Ids" - if it shows PID_0000 in the end - it's already "killed". The driver really re-writes PID in the chip's EPROM. Correct PID is 6001.
You're right - quick interrupt, or some sort of quick bounce of ac will shut the amp down, indicating AS Failure. Longer interrupt will lead to Arduino restart, initiating the soft-start sequence again.
With regards to unbricking.
First of all - see the driver version you've got now.
Device manager, right-click on your controller port, "Properties" -> Driver tab.
If it shows 2.12.0.0 - that's the latest "killing" one.
On the Details tab select "Hardware Ids" - if it shows PID_0000 in the end - it's already "killed". The driver really re-writes PID in the chip's EPROM. Correct PID is 6001.
For unbricking, you need to unzip both files I've sent you.
First of all, in Device Manager / Properties, go to "Driver" tab again.
Click "Update Driver".
"Browse my computer for driver software" (bottom choice).
"Let me pick from a list of device drivers on my computer" (bottom choice again).
"Have Disk". "Browse".
Then point to your FTDI driver 2.8.14 driver and setup ftdibus driver first, and then do the same thing with ftdiport driver (converter and port drivers respectively).
Go to Device Manager / Properties, "Driver" tab again - you should see 2.8.14 version of the driver now.
First of all, in Device Manager / Properties, go to "Driver" tab again.
Click "Update Driver".
"Browse my computer for driver software" (bottom choice).
"Let me pick from a list of device drivers on my computer" (bottom choice again).
"Have Disk". "Browse".
Then point to your FTDI driver 2.8.14 driver and setup ftdibus driver first, and then do the same thing with ftdiport driver (converter and port drivers respectively).
Go to Device Manager / Properties, "Driver" tab again - you should see 2.8.14 version of the driver now.