Real time can mean different things to different people. What frequency do you need to IO monitor to update?
FTP backups have been discussed on the forum several times before, please do a search first. It's pretty simple just connect to the robots IP address and you can do any normal FTP commands.
One thing you may be able to do is to send the IO status from some signals through socket communication, but as far as I know, to do that you need the socket message option (R648) in order to send data that way.
See this thread: Socket Messaging with C #
I currently use a similar way to transfer data from the robot to an external PC, but you must parse the data and send it on various bytes, then on the server side decode that information again and reconstruct the data you have just sent.
You can find usseful info about how to setup this on the "Karel reference manual"
Another possible way, but I don't know if will work, is trying to access the IOSTATE.DG file using the FTP, but I think it will be a bit messy to just download that file every second and parse it.
You may be able also to write a file inside the MD directory using Karel with the status of signals you are interested, download and parse it.
If you are just doing I/O you could just trend the I/O with a PLC or a Tmanger is a great way to track stuff like that for that. Very easy and cheap! Like HawkME Real time means different things, do you want REAL TIME or just a history of what happens. The 2 options I said are cheap but would be the history
One more thing I have read before with getting stuff like that is having a excel' s coded program in it like a Marco and it can track that kind of stuff.
100% depends what you want and what you want to spend but I would personality not make a program for that kind of of thing unless it would be easy for you.
I would also ask reddit in the PLC forum.
Also what have you found for the FTP? I would like to hear more.
Socket messaging is out of the question for me, parsing IOSTATE.DG would be the last resort. For finding out the main problems of a robotic cell during production without exaggerating with mget>parse loop what interval would you recommend?
The last solution sounds verry good and less messy. I guess you are talking about a background program that continuously running. Unfortunately I don`t have any idea about how it would look.
Reading the IOSTATE.DG would be the best way, because if you write the IO info every second on a file inside the MD, I don't think the SD card or whathever fanuc uses internally to store the files would survive the constant write cycles over a year.
If you want to do it the other way writting ony the variables you want on a file, you will need to do it with Karel... there is not other way to do it since the TP instruction set is not ennough to do that.
You will need to get info from the signals you want, parse them to text and overwrite (or append) the lines from that file every 1sec per example.
You can do it with a background program you can call with the "RUN" instruction or launching it on the hotstart through the "Config" menu.
I do not remember if it's possible to access the ramdisk through FTP... if it's possible, then you can do it with Karel but writting the file inside the ramdisk so no damage is done to the memory card...
This is not a good method, best way would be to send the information to the PLC and then read it using something like an OPC server from the PLC DB... if you do not want to use socket messages, and you also don't want to use a PLC, I don't know any other method.
If you use FTP then I wouldn't do an mget. Just get the single IO file. You would have to experiment with timing. Maybe try every 10 seconds and see if it is reliable, then adjust.
Well, to give you the full story : I`m from a part of the world where they don`t "teach you robotics in school" and for the past years I just got from project to project just touching up points, making sure that the process works fine not big brainy stuff.
Lately I got interested programming and start learning python and what a better way than trying to automate my work. I built some pretty neat stuff. I got courageous and I outlined the perfect project: An app that can help me in the integration process from A to Z but now I`m wondering if it`s too much to chew.
To be honest with you guys I don`t have so much knowledge in Karel language and how a lot of robot stuff works so sorry if some of my questions sound dumb.
For the FTP I will use "ftplib" for sending the comands from python(i will test tomorrow if it works):
"
import ftplib
robot_ip_address = "!RobotIPaddress!"
local_folder = "!root!"
ftp = ftplib.FTP(robot_ip_address)
ftp.login()
ftp.sendcmd("binary")
ftp.sendcmd("prompt off")
ftp.cwd(local_folder)
ftp.mget("*.*")
ftp.quit()
"
Edit: PLC is out of the question in my case as it requires extra setup steps and social engineering to convince someone to help me 
Edit2: I previously made a function that parse trough all informations about the pints from an.LS file so IOSTATE should be a piece of cake.
Edit3:Well sounds like I got my solution with parsing of IOSTATE and found the same answer for my two questions. Thank you so much guys, you are the best! I hope I can sometime give back to this community !
It's not all about the experience you have or what you have learn't in school, but about how much you want to improve and learn...
Having a previous base of programmation helps a lot in this world, but I've seen much people that with effort, becomes a great robotics, even without previous kwnoledge on the matter.
Knowing how a PLC works helps as well to diagnose much problems, and I always recommend people who are interested to learn a few things about that.
The major part I've learnt was by searching throught the system variables, reading manuals and solving problems, nobody gets here with all learned.
When I started as robotic, even as I have received formation on the matter, the first thing I learn't was that I had no idea in reality...
This forum and people who are here also helps a lot, so many headaches avoided by doing a quick search, here and there, and when you discover some tricks you will become more confident about what can and cannot be done.
I've also coded some applications to analyze fanuc programs from an .ls backup, but it's a nightmare to parse all data and types of instructions.... I find sometimes new modifiers I haven't contemplated and need to do corrections.
I hope there was a way to do a quick search on the fanuc program for registers being used without the need to analyze all the program by hand, as I haven't found a way I needed to do it myself.
Maybe on the future I will publish it, but it's still in development and there are several bugs to address.
