Mains fail Detector

Post by **greentech** » Mon Jan 31, 2011 7:12 pm

How can i use flowcode to design a mains fail detector circuit using pic 16484a and transfer to inverter mode in less than 2 milliseconds.

Post by **Benj** » Tue Feb 01, 2011 9:53 am

Hello,

have you tried looking for reference projects online? Im guessing most of the work is the physical electronics to do the mains sensing and the Flowcode program will be fairly straightforward.

Post by **greentech** » Tue Feb 01, 2011 9:55 pm

Thanks for replying.

Ill look for the resources online, then get back to you if the problem persists.
Yesterday i was playing around in flowcode. I developed a simple lcd ascii display which simulated in flow code well. But in the real world it displays only 8 characters, i fixed the problem by adding cursor and breaking the line into two parts. This creates a problem in scrolling the text onto the display. is there any reasonable way to do this? i am using DMC16105 Optrex 16x1 lcd. rw pin gounded db0-db3 left open. db4-7 connected to rb0-rb4
i am using pic16f84a. 4MHZ. Hardware is rightly connected.

Post by **medelec35** » Wed Feb 02, 2011 6:56 am

greentech wrote:This creates a problem in scrolling the text onto the display. is there any reasonable way to do this? i am using DMC16105 Optrex 16x1 lcd. rw pin gounded db0-db3 left open. db4-7 connected to rb0-rb4
i am using pic16f84a. 4MHZ. Hardware is rightly connected.

What about enable pin?
I'm not sure if this will help you to to get round the display problem as I've not heard of only able to use 1/2 of display (sounds faulty to me, but I could be wrong).
As a temporary solution, have you tried to scroll text one char at a time?
For Flowcode V4 see: http://www.matrixmultimedia.com/mmforum ... 09&p=15771
For Flowcode V3 see: http://www.matrixmultimedia.com/mmforum ... 17&p=15777

As for mains detection, you could use a small transformer, to step down AC to a low level. Connect a diodes to form a full wave rectifier then use a very low value cap(High enough just to keep voltage a logic 1 level , low enough to discharge quick enough in event of mains failure),with a resistor in parallel with cap. Then use int interrupt on falling edge, or port B ioc to detect failure.
A more dangerous method, is to use an either AC optocoupler connected to mains via two series resistors e.g. 120K or DC optocoupler with diode connected in inverse parallel, again cap to keep voltage above logic 1. Since connected to mains you must do at your own risk, as mains can kill.
I would not recommend the optocoupler way unless you know what you are doing, and make sure there no risk of shock from the pcb.

goldwingers · Post by **goldwingers** » Fri Feb 04, 2011 6:45 pm

I would think your never going to achieve your goal as mains frequency is 50 cycles per second to achieve 1 cycle that equates to 20mS. Any program will need to pass the zero crossing point which would be at 10mS as a maximum time limit. So for your 2ms you would be looking for the beginning point of a cycle or a zero crossing point. The processing power alone takes you outside the 2mS barrier.

I work with professional transfer switches that cost thousands of ££££££'s and they achieve around 3.5 <> 5.0mS.

However if you manage it, You will be worth ££££££'s.

Ian

Post by **medelec35** » Fri Feb 04, 2011 8:34 pm

goldwingers wrote:I would think your never going to achieve your goal as mains frequency is 50 cycles per second to achieve 1 cycle that equates to 20mS. Any program will need to pass the zero crossing point which would be at 10mS as a maximum time limit.

Whilst that is true what you have said, that's the reason I not gone with detecting AC but instead suggested DC full wave and discharge cap quick. Diodes can also be used to slowly charge cap(via higher value resistor) and quickly discharge cap (via a lower value resistor) in event of mains failure. Cap value has to be chosen so is low enough to discharge at fast enough rate, in event of mails failure, but not too low to discharge too much as waveform nears to zero point.
I'm not saying it will work 100% successfully, but you don't know till you try

.

Post by **greentech** » Sat Feb 05, 2011 6:02 am

The DC method seems to work but not all the times. At times it takes more than 10 ms. I am using 1uf cap with 1k resistor I will now use the interrupt on falling edge and see if the problem is resolved.

As i am exploring flow code. What do u recommend to receive an audio signal? Is it OK to analogue input the audio signal and then output it via PWM? or TX pin?

Post by **medelec35** » Sat Feb 05, 2011 8:56 am

if you don't mind posting the circuit diagram, and flowchart I will see if I can improve it for you. I won't get a chance to test it until Monday. If you can't share it, then you can pm it if you like. I believe the interrupt route because it takes a certain time looping round to checking the input pin value. with interrupt it should be instantaneous. I can't guarantee it will work, as its just my theory. Never tried with audio signal. But if you say how you want the audio signal to affect PWM, then I will have a think about it.

Post by **greentech** » Sat Feb 05, 2011 12:30 pm

Haven't made the schematic yet. Just planning to input audio signal via microphone to output the recieved data by rs232 component. I will also use a dac to convert the Tx signal for converting it to analogue again.

What about midi component?

Post by **greentech** » Sun Feb 06, 2011 5:38 pm

As i am testing the flowcode before i buy it. I am discovering alot of problems. Vnet also not working.
when i hit create it returns with a message "Cannot connect to Vnet."

Post by **Steve** » Mon Feb 07, 2011 8:21 am

To use VNET functionality you need to launch the VNET Server (it's in a subfolder of Flowcode/Tools). If there is still a problem, then your firewall could be blocking communication on the port it is set-up to use.

You also say there are a "lot of problems". Please list them and we'll try to help you overcome them.

Post by **greentech** » Mon Feb 07, 2011 10:08 am

Thank you Steve,
The Vnet is working fine now.

GLCD is very slow.
Cant display 16 characters on the 16x1 LCD. Only get 8 Character, I have to divide the text into two parts for displaying 16 chars.....then im left with the scrolling problem.

One wire is very confusing. No matter what i do i get a 0 only. no other number. I was trying to get the temp.

Rs 232 component is working well but just a little problem, when i transmit the data for example "3.43" and display this onto the lcd it prints fine except the last digit. it keeps on changing very fast. Varying the potentiometer helps.

I would love if you guys manage to put some training video online for all the components. Specially custom components. It also gets hard when i am unable to simulate custom components. such as can bus etc.

I will check more of it today and will post u the update.....

Post by **Steve** » Mon Feb 07, 2011 10:30 am

Glad the VNET is working.

The simulation of the GLCD is slow, but there should be no problem when using the actual hardware. For example, we've recently written a game on it (using Flowcode) that we've had to slow down to run at 20 fps.

Your issue with the LCD seems strange to me. We have used many different varieties of this LCD with no problems. I've checked and it does use the same controller, so that should not be a problem. However, the controller might possibly be wired to the actual display in a strange way. This controller has an internal display buffer of (from memory) 64 bytes. This is mapped to the actual display in different ways on different LCDs. For example, a 2x16 display usually maps bits 0 to 15 of this buffer to line 1 of the display and bits 32-47 of the buffer to line 2. Have you tried writing to the whole buffer to determine how the mapping occurs on your particular device?

One wire seems to have a number of issues and the way this works seems to vary from device to device. I am not familiar with this myself, but I know others have had issues with using particular devices. If you post more details, then someone who has used your particular device may be able to help.

I'm not sure where the problem is with your RS232 comment. It sounds like the LCD to me, or perhaps the way the data is being displayed. If you provide us with a simple program that exhibits this behaviour, then we'll be able to test it and see where the problem is.

Post by **greentech** » Mon Feb 07, 2011 5:37 pm

Steve i am using optrex DMC16105 lcd, 16x1. Problem is simple, if i print ascii usinf cursor 0,0 it displays only 8 characters. But when i print only 8 chars at cursor position 0,0 and rest of them at position 0,1 it displays full 16 chars. It seems fine, but the major issue as the text splits up when i scroll. Did you write the game code using flowcode? I will try using a different LCD now and update you. Did RS232, i will look into the code tonight, probably its the return value of 255? i am using one wire as a general component where it have to return the value of 18b20 which it doesn't and always return 0. Have you tried blue tooth & GPS?
I will also request you to enhance the graphical appearance of "COMMS Components" such as can bus, bluetooth, fat, tcp etc..

RS232, SPI, Irda looks great and gives a very clear idea in simulation, these are just more user friendly. Is there is any new version coming out soon. A version that could work on i-phone will be awsm.

Post by **Steve** » Tue Feb 08, 2011 7:41 am

Regarding your character LCD, it is as I suspected - the internal wiring of the controller chip to the actual display is a configuration I've not seen before. This means that the scroll function will not work as you have described - but this is a fault of the LCD itself and nothing to do with Flowcode.

The game was written using the new dsPIC/PIC24 variant of Flowcode and our standard gLCD.

If you are interpreting the return of 255 as a valid return from the RS232 component, then your program may behave strangely. This is how it works in "legacy" mode, when the return is limited to a "byte" value. The other mode will allow a return as an "int" and so you will be able to receive any legitimate value between 0 and 255 (or 511 if you're using the 9-bit mode).

Bluetooth and GPS work fine in my experience.

Simulation of the CAN component needs to happen using the VNET. We currently have no plans to allow simulation for Bluetooth, FAT, TCP, and other "advanced" comms components. Simulation in Flowcode will never replicate what happens in reality and we see the real value of simulation in simpler applications and when first learning Flowcode. The ICD functionality is a much better way of debugging more advanced programs.

Finally, I doubt whether we'll release a version of Flowcode for the i-phone any time soon (although I agree it would be great!).

Post by **greentech** » Thu Feb 10, 2011 8:57 am

Ok Steve here is a very strange problem Regarding Keypad.

A very simple program getkeypadnumber and return into variable kpn.

if kpn =255 print 255 on LCD. "YES "
If "NO" Print kpn on LCD.

Simulates well, but on the hardware it behaves differently. It is returning different values randomly. sometimes it is 255, at times it is 0, 3, 7 etc.

Keypad connections double checked infact triple checked. Keypad is connected to PortB & LVP is diabled.
Using 4x4 keypad. the problem is same with 4x3 keypad. No pull ups or pull downs on portB. Connected directly to keypad. Operating at 4MHZ.
Do i really need pull ups or downs?

Post by **Steve** » Thu Feb 10, 2011 10:11 am

Sounds like a dodgy keypad or something in your program that is interfering with the reading back from the keypad. Do you have the same problem if you create a very simple program and keep the connections to the chip to a minimum?

Post by **greentech** » Thu Feb 10, 2011 10:35 am

yes. the program is as simple as i mentioned i have tried with minimum connections also but invain. Looks like something is not rite with flowcode keypad component.

Post by **Steve** » Thu Feb 10, 2011 12:22 pm

I'm a bit surprised at this - this is an often-used component and we've not had this issue before. Please post your FCF and C code files and I'll have a look to see what's gone wrong.

Post by **greentech** » Thu Feb 10, 2011 12:30 pm

Here is the file which i am using to test keypad and lcd.

Post by **Steve** » Thu Feb 10, 2011 12:56 pm

Doesn't seem to be anything wrong with the program. It could be the keypad.

One thing to try is to change the program (and hardware) so that the keypad is on portd and the lcd is on portb. This might rule out an issue with the chip.

Also I see that this is a V4 program, yet you've posted to the V2/V3 forum. You can gain access to the V4 forum using the "online resources" button in Flowcode.

Post by **greentech** » Thu Feb 10, 2011 1:26 pm

Now Lcd is not working. Not really getting any idea about keypad. I dont really think the there is a chip problem. tried with 3 different chips. 16f877a.
is flow code configuring port b rightly?

Post by **DavidA** » Thu Feb 10, 2011 2:40 pm

Hello,

To continue to recieve support on this issue could you please get your account upgraded to be able to post on the V4 forums, once you have done this i will move this topic there.

If you have trouble doing that please see this FAQ topic: http://www.matrixmultimedia.com/support ... f=29&t=602

Additionally the 16f877a is one of our most used chips, and used in all our eblock bundles and a lot of our examples, if there was a problem with port B it would have been recognised and fixed very quickly.

Post by **greentech** » Thu Feb 10, 2011 2:46 pm

how can i upgrade? to v4 forums

Post by **DavidA** » Thu Feb 10, 2011 3:04 pm

Please see the link i gave in the last post, it contains a full walkthrough of how to upgrade your forum username to be able to post in the v4 forums.

Matrix user forums