I would like to be able to press a button on an HMI and have it both acknowledge an ALMD/ALMA alarm in the PLC and also acknowledge it in the Alarm List in the HMI. With a FT Alarm and Events server for FTView SE this would be a piece of cake, but unfortunately I'm running this on a machine.
My thoughts were to somehow use some type of PB to connect to a tag in the PLC to acknowledge the alarm there and also connect it to a macro to push the standard Ack Alarm button that you can link to the alarm list.
Would anyone know how to do that? Or have a better idea of a way to do what I am trying to do?
Thanks
This may be a better way:
On many automation platforms (ones that don't utilize the Alarms and Events feature on HMI's) a simple way to do it would be by storing an integer in the PLC. This integer would represent the "Fault Code" or "Alarm Code".
Based on watchdog conditions in the PLC, a different non-zero integer would be moved into the Fault Code address for each fault.
When the Fault Code is not equal to zero, a Fault Bit is active.
This Fault Bit would trigger the alarm screen on the HMI. The "Clear Alarm" PB on the HMI would attempt to move a zero to the Fault Code, and also attempt to re-start the automated sequence or process, in an attempt to "Reset" the fault. If successful, the fault would be cleared. If the attempt is unsuccessful, the fault would simply remain active.
As long as the alarm is displayed on the alarm screen, the HMI will log the fault.
Related
I'm facing an unexpected problem with stm32f103c8. I'm programming the chip and after reset, it starts to run the program, but after a few seconds the microcontroller getting mixed up and stops running the program. After that when I try to reprogram the microcontroller, IDE(IAR EWARM) tells "target held in reset state".
It's very unusual issue because sometimes when I connect nRST pin directly to the VCC(3.3V), microcontroller runs program but unfortunately the current goes over 120mA and chip breaks down finally.
I'm using STM32CubeMX to generate the codes and my programmer is STLINK V2(clone), also tried Jlink V8.0(clone) but didn't change the result.
Could it be because of the clone programmers?
Can anyone help me solve this problem?
Thanks
Never connect nRST directly to VDD/VCC. This is a bi-directional input-output which must only ever be connected to an open-drain/open-collector signal. It can be pulled low externally or from within, it must never ever be pulled or driven high other than by the internal pull-up resistor.
When your debugger or programmer has finished programming the flash and wants to start running the new program then it requires to be able to pull this line low, which it might do externally if you connect this line to it in hardware, or else it has to be able to pull it low by software using the internal reset pulse-generator. If it does this and you have tied the line high externally then you are effectively shorting out your power supply, which is the cause of the over-current condition that you have observed.
Maybe the original problem is that your counterfeit ST-Link has its reset output configured as push-pull when it should be open-drain.
I would suggest that the easiest way to proceed is to leave the nRST line unconnected and configure your programming tool to use a software reset only.
My problem is related to SIM800 connection messages.
I use the module with STM32 developlment board. Sometimes module is reporting SMS Ready and Call Ready messages respectively. When I start to send AT commands to the module, it may send these messages (it doesn't happens all the times).
However, the commands I previously sent are apparently unrelated (for example HTTP commands), and SMS Ready / Call Ready messages is coming while they are not expected.
Because of this reason, Keil is reporting "Can not access" message in the debug session. Is it possible that disabling these messages when the connection is established? Or it means that module has an unexpected reset?
According to SIM800x modules AT commands guide, SMS ready and Call ready are URCs (unsolicited result codes) sent at startup as soon as the capabilities to deal with SMS and to perform calls respectively are correctly initialized and available.
So this is the first bad news for you: if you see them it probably means that your device reset due to a bug or as a consequence of one of the commands you previously provided.
The second bad news is that on the AT command guide linked above there's no mention of the capability to disable SMS Ready URC.
There's fortunately at least a good news: Call ready can be disabled by means of AT+CIURC command:
AT+CIURC (Enable or Disable Initial URC Presentation)
Syntax: AT+CIURC=<mode>
<mode> : 0 Disable URC presentation - 1 Enable URC presentation
Note: When module is powered on and initialization procedure is over URC "Call Ready" will be presented if is 1.
The guide also mentions the fact that this setting is saved in the profile area. So, in order to make sure it is persistent to reboot, after issuing the command store active profile:
AT&W
OK
For me, receiving a lot of messagens Call and SMS ready was a problem on current not enough to keep the module working.
(You can check it too watching the led blinking, if it blinks 6/7 times and stop for a while and restart over again, you have the same problem)
Just to SIM800 keep working is necessary at least 700mA.
Ps.: You can connect directly to your battery 18650 (3.7V-4.2V).
If you are using TP4056 module, you must remember there is 1A max current. try to connect in parallel more than 1 TP4056.
Lets say we have an 8 core system running linux and you are using GUI desktop and have 10-20 terminal open.
When you type something, the user input appears on the correct terminal. How does that happen. For example the keyboard interrupt can arrive on any of the cpu, how is it routed to the correct process is my question (given that at a time 10 processes are waiting for user input)
This is what I know:
Keyboard driver will have an interrupt handler that reads the input and copies it to a buffer which might be processed by some high priority work-queue. (not necessary but that is what I feel will happen)
This buffer has to be copied into buffer of the file descriptor for stdin of the currently active shell.
What I don't know
How does the work-queue work function determine which process is running the currently active shell.
It just does know. One of all of the process is marked as the current for console I/O. You switch to another, that other gets marked as the current. I don't know the details of the implementation, but that's the idea.
The work queue function does not determine which process is running - this is done at a much higher level. The keyboard device is exported by the kernel through a device file in /dev/input/ (on my system it is /dev/input/event3 - you can look at /dev/input/by-id to see which one corresponds to your keyboard). This device file is opened by the X server in order to receive the events (look for the device file in /var/log/Xorg.0.log to see where this happens). The X server thus receives all the keyboard events and dispatches them to the right client itself. Knowing which window has the focus, it can put the corresponding input event into the client queue queue and send a signal to the corresponding process, which is waken up and can process the event.
See http://en.wikipedia.org/wiki/Evdev and related links for more information.
We've got a requirement to determine whether the user is waiting on a program to do something. The biggest issue I see here is, if I monitor user activity (Keyboard and Mouse) then I'll assume the user is waiting when they might be reading, thinking, on the phone, etc.
Sometimes, if I know I'm going to have to wait a long time on a process (like booting up), I'll go get a coffee whilst it loads. I'm not really waiting on any one program, I'm just being efficient with my time.
I'm open to any ideas, even requesting the user use a key or key-combination to indicate they're waiting.
Is there a way to determine whether a user is waiting on a program?
Give the user the illusion that they could do the next step of interaction, i.e. don't tell them right away that the previous action has not completed. Then, when they try do something, you'll notice that they really would like to do something now and hence are waiting if they can't.
In some cases, you may find that what they want to do can actually be done right away, despite the previous action still being in progress.
You can't tell what a non-interacting user is doing. They could be day dreaming and you'd have no idea if they were waiting on the computer or not.
You might be able to deduce from user interaction that a user was waiting when you see no activity during a period of time when disk and or CPU usage is high. But this is not a scientific measure, it's merely an indicator. The assumption that the user was waiting negates the possibility to use the results for meaningful measurements.
My iPhone application supports a proprietary network protocol using the CocoaAsyncSocket library. I need to be able to send a network message out when my iPhone application is closed. The code that sends the message is getting called from the app delegate, but the application shuts down before the message actually goes out. Is there a way to keep the application alive long enough for the message to go out?
Bruce
The docs from Apple don't specifically state this, but the sense I get from looking around the Web and from personal experience is that you have about 4 to 5 seconds after the user hits the Home button to shut your app before your application actually terminates. The iPhone OS is controlling this so you can't block the termination to allow your program to finish first. Basically when your time is up, your program is killed.
There may be another solution, though. First I'd confirm that your code is really taking more than 5 seconds to run. Perhaps you can have it run in response to a button tap, and time how long it runs. If it is more than 5 seconds, you probably are running into this time out issue.
You might then find a way to trigger a message to be sent from a server that is always running. You should have enough time to trigger a remote action, which in turn could then take as long as it needs to run.
Or perhaps you could save the vital information to the iPhone file system on exit, and send that message the next time someone starts the application, which should theoretically give you enough time.
Hope this helps!
I assume you're already calling it from your AppDelegate's:
- (void)applicationWillTerminate:(UIApplication *)application
But as you've discovered there's no guarantee it'll be called or will be allowed to finish. There are a few options that may or may not work depending on what you're trying to do:
If you need the server to perform some sort of cleaning operation triggered by when the client app is gone then you could try watching for TCP socket closure on the server and treating that as the triggering event. But if you explicitly need to send data back with the closure this may not work.
If the data you're sending back is not time-sensitive then you can do like most of the analytics libraries do and cache the data (along with a uuid) on the client then try to send it on app closure. If it goes through, you can clear the cache (or do it the next time the app is run). If it doesn't, it's saved and you can send out when the app is run next. On the server, you would use the uuid to avoid duplicate requests.
If the material is time-sensitive then your best bet is to implement heartbeat and send periodic updated values to the server. Then when the client app dies the server times out the heartbeat and can use the last received value as the final closing point of data.
In either case, if an explicit closure event is required by your custom protocol then you may want to reconsider using it in a real-life mobile environment where things have to be much more fluid and tolerant of failure.
As others have noted, there's no way to be absolutely certain that you'll be able to send this, but there are approaches to help.
As Ken notes, you do in practice get a few seconds between "willTerminate" and forced termination, so there generally is time to do what you need.
A problem you're almost certainly running into is with CocoaAsyncSocket. When you get the "willTerminate" message, you're on the last run loop of the main thread. So if you block the main thread, and CocoaAsyncSocket is running on the main thread, it'll never get processed. As I recall, CocoaAsyncSocket won't actually send all the data until the next event loop.
One approach, therefore, is to keep pumping the event loop yourself:
- (void)applicationWillTerminate:(UIApplication *)application
{
// ...Send your message with CocoaAsyncSocket...
while (! ...test to see if it sent...)
{
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}
}
I've also looked at putting this work onto a background thread and letting the main thread terminate, in theory letting us go back to Springboard while continuing to run for a few seconds. It's not immediately clear to me whether this will work properly using NSThread (which are detached). Using POSIX threads (which are joinable by default) may work, but probably circumvents any advantages of the background thread. Anyway, it's something to look at if useful. In my apps, we've used the "post next time we launch" approach, since that always works (even if you crash).