Is there any way to look for console input under MicroPython without pausing the program?
Within a program, I can use, for example, uart1.any() to see if there is anything in the input buffer. If not, the program can just continue.
I have a system that runs autonomously. However, I want to be able to modify parameters after the program has started using the console. The problem is, if I just use input() then the program will pause, even if I don't want to take any action.
What I need is to be able to check the "console input buffer" periodically to see if I have entered anything and, if so, process that input, otherwise to just continue.
Is this possible?
=====================================
Many thanks for the suggestion! It works, but...
What I am trying to do is to run a process which can be interrupted by keyboard input and diverted to another process. When that is finished, I return to the original process.
The initial part works well; I poll stdin and nothing happens until I hit return (for example). The program then correctly diverts to the other routine. However, when that is finished, and I return to the original thread, it immediately diverts again, even though I have not pressed any further keys.
I have tried setting 'keypress' to None after trapping it; I have tried using stdin.flush - which doesn't work! It's as though there is still something in the input buffer that I need to purge.
Any ideas?
You can poll stdin to see if data is available before attempting to read it.
from sys import stdin
from select import poll, POLLIN
poll_obj = poll()
poll_obj.register(stdin, POLLIN)
keypress = stdin.read(1) if poll_obj.poll(0) else None
print(keypress)
Related
I'm writing a program in LabVIEW 2014 in order to control a linear actuator. The program is very simple, it sets a speed and then runs the subVIs to move the actuator back and forth.
There is a case structure inside a while loop so it would stop when a desired number or iterations is reached. The problem is that the iteration count of the while loop occurs faster than the execution of the program inside the case structure, and therefore the program stops before all the cycles of movement have been completed.
send pulses subVI:
activate subVI:
I tried different time delays in different parts of the code, but none of that worked. I think that the issue is that the while loop iterations run faster than the code of the case structure and somehow I need to slow it down. Or maybe I'm wrong and it is a complete different thing.
Here is the link of the actuator documentation:
https://jp.optosigma.com/html/en_jp/software/motorize/manual_en/SRC-101_InstructionManual_Ver1_1_EN.pdf
Welcome to the fun and infuriating world of interfacing to serial instruments.
Each iteration of a LabVIEW loop can only complete once all the code inside the loop structure has completed, so it's not possible that 'the while loop iterations run faster than the code of the case structure'. There's nothing explicitly wrong with any of your code, but evidently it isn't doing what you expected it to. The way to approach developing an instrument driver is always to start with the simplest case (e.g. one single movement of your actuator), get that working, and build up from there.
The documentation for an instrument's serial interface is rarely perfect and yours is no exception, but it does tell us that
every command is acknowledged by a response, and
you should not send a new command until you have received the response from the previous command.
Your code to send commands and receive the response looks OK. A VISA Read operation will read bytes from the computer's serial buffer until either the number of bytes to read is reached, or a byte matching the termination char is read, or the timeout expires. The manual implies that the instrument's responses are followed by the CR and LF characters, and the default configuration of the serial port in LabVIEW is to terminate each read when an LF is received, so you shouldn't need a time delay between each write and the following read; the instrument's response will be received into the buffer by the OS, then your code will read it out and return it as soon as it hits the LF.
What isn't completely clear from the manual is how the instrument responds to the activation command, G: - does it
Return the acknowledgement immediately, then execute the movement: you can check whether the movement is finished using the status command !:, or
Execute the movement, then return the acknowledgement to show that it's finished.
I think it's 1. but that's the first thing I would check. Unless all your movements are completed in less than 500 ms then I think this is what is wrong here: your program receives the acknowledgement then moves straight on to send the next command, but the actuator is still moving and not ready. In this case you have two options:
add a time delay after the read, calculated to be long enough for the actuator move to finish - this would be easiest, but potentially unreliable
in a While loop after you have got the acknowledgement of the G: command, send the !: command and check the response until you get R for 'ready'. (Remember that the acknowledgement string you receive will also have the CRLF on the end.) Use a time delay in this loop so you don't bombard the instrument with status checks - maybe something like 200 to 1000 ms would be suitable.
If it's case 2. then you would also have two options:
configure your serial port with a read timeout long enough to cover the longest move operation, then the read operation will just block until the acknowledgement is received - again this is the quick and dirty way, or
configure a short timeout, say 1000 ms, and place the read in a While loop that repeats until the acknowledgement is received or too many timeouts have occurred. Note that a timeout is considered an error, so you will have to turn off automatic error handling for the VI and instead test the error wire out of the VISA Read, discard the timeout error and handle any other error yourself.
Just as a general tip, whenever you pass an error wire into a loop and out again, I would use a shift register. That way if one iteration generates an error, the next iteration will see that error and fail immediately, so (for example) if communication fails you don't have to wait for the read timeouts to expire multiple times before your code can exit.
You'll probably have to do some experimenting and referring to LabVIEW help to get this fully working but hopefully this is enough to get you going.
I have observed that even if i stop a node or a participant by pressing ctr + C, i.e. terminate it...it still shows in the Admin console or 2 minutes or so. Why isnt it immediately derigestered. Is there a way to do so ?
At shutdown of your application, you should clean up the DDS entities, as demonstrated in this piece of example code. In a nutshell, it invokes the following methods:
DDS_DomainParticipant_delete_contained_entities(participant);
DDS_DomainParticipantFactory_delete_participant(DDS_TheParticipantFactory, participant);
If you do not do that, the DDS discovery process will detect by itself after a while that the Participant has gone. The responsiveness of this mechanism is configurable, as explained in the knowledge base article What settings affect DomainParticipant’s liveliness?
Now pressing Ctrl+C normally will not execute the code described above, because the signal will terminate the process right away. As far as I know, the only way to avoid that is to install a signal handler that invokes that clean-up functionality. Here is a gist with some example code on how to install a signal handler: aspyct/signal.c.
I am writing a client-server project using TCP protocol, so in my client code I have a while loop with a read() in it that waits for a write() from the server.
I think that this is irrelevant to the question I'm actually asking, however, this is what causes my problem which is that while the client is waiting for a write() from the server, the user can type sentences on the terminal that get stacked on the input buffer, so when my client finally receives a write() and moves on from his read(), I can't clear the input buffer with the usual way of clearing every character until the new line character is found:
while (getchar() != '\n');
because the user has typed many sentences and pressed enter multiple times while he was waiting.
Is there any way that I can fully clear the input stream no matter what is in it?
All I found out so far is that I can use fflush(stdin) and, although unconventional, it works for me, but sometimes it doesn't so I can't use it.
I also tried checking the input stream's end with:
while (getchar() != '\0');
But it gets stuck in an infinite loop. I also tried using a scanf() that ignores new lines after read():
scanf("%[^\r\t\n]s", buf);
so that everything would get moved to this buffer, this didn't work either, only the first word from the last sentence typed gets stored there.
Lastly, I tried messing around with fgets() but no luck there either.
P.S. Is there any way I can completely disable the standard input stream before the read() call and enable it again right after?
Edit: For archive purposes, I actually forked my program at this point as to continue scaning inputs and instantly clearing them with the standard first way I mentioned. Still, I would like to know if there is a way to completely clear the input buffer no matter what's in it.
This seems promising:
Basically what he/she is doing is using fgets with fflush..
https://www.daniweb.com/software-development/c/code/217396/how-to-properly-flush-the-input-stream-stdin
Does anyone know how one can automatically reply to messages with status MSGW that block a job on an IBM i-series (AS/400)?
I'm using the jt400/jtopen library to access a program on an AS/400 from Java. I'm using the com.ibm.as400.access.ProgramCall class, which works fine, unless the program fails for some reason. As with almost any program, failures will happen sometimes, but unfortunately, in this case, it does not result in a status message or an exception. Instead, the calling thread just hangs. What's worse, any call to the AS/400 to get information on the Job (another class in jt400 that mostly does what you would expect) backing the queue will hang as well.
I could of course monitor the thread in which the call runs and simply kill it after waiting for a while, but that's a last resort. Getting an error message back from the system would be nice.
You could try execute this command before invoke your pcml with com.ibm.as400.access.CommandCall.run() method:
CHGJOB INQMSGRPY(*DFT)
It sets 'C' as default answer for all messages.
but you should ensure you have log of the messages in order to know the problem which generates this message
Regards,
I don't believe Java can directly trap errors that occur on the other side of that API. What I've done is to 'harden' the RPG (IBM i side) program so that it monitors for errors rather than let the default error handler get them. When an error occurs, the RPG program gracefully terminates and passes back an error code or even the entire message back to the Java application.
I've found that you can use the timeout mechanism of ExecutorService to interrupt a ProgramCall in MSGW.
You must discard the AS400 object afterwards, and the server job is still in MSGW, but at least you can continue on the Javaside.
(You need to use a separate AS400 object if you want to investigate on the hanging job.)
From my own "key logger like" process I figured out that another process Locale is wrong (i.e. by sniffing few keys, I figured out that the foreground process Locale should be something while it is set to another). What's the best way to do this?
I'd use setLocale from within that process to change it, and notify the process about this with some form of IPC like:
signals
sockets
pipes
from the process who knows
You didn't specify operating system or anything, but in Linux this is quite hard unless the target process is willing to help (i.e. there's some IPC mechanism available where you can ask the process to do it for you)
What you can do is to attach to the process, like a debugger or strace does, and the call the appropriate system call (like setlocale())
The result on the target process is of course undetermined since it probably doesn't expect to get its locale changed under its feet :)