Just to clear up something: do I understand you correctly when I believe that you are trying to reverse engineer the protocol used by kfloppy when it's communicating with the controller? In order to create a VB reimplementation which would remove the need for kfloppy altogether?
Posts by rf103
-
-
In regards to the R2000 style, I beleive the iA has J4 move, where J4 doesn't on the iB. That's one difference I know of. Probably just have to pull some spec sheets from Fanuc to find out the big differences.I'm not sure I follow: "iA has J4 move, where J4 doesn't on the iB"?
I also thought the electrical control boxes were different sizes.Yes, disregarding controller changes I guess.
-
Not sure this can be answered for the general case, but is there any way to 'predict' or recognise what kind of changes there may be between the various generations (if that's what we should call them) of robot models? Or in other words: what makes Fanuc decide that a robot should be an iA/iB/iC/iX?
The LR Mate is the clearest example where even their physical appearance changed going from iB to iC to iD (curiously there appears to be no 'iA', probably to not confuse them with the larger robots?), but for other models such as the R-2000 iA and iB (or the M-710iA/iB/iC) it's not really clear where the (biggest) changes have been made.
-
there is also a variable for robot in motion.so after a move, I have used wait $(robot in motion) = off, before doing next command.
Probably $MOR_GRP[n].$ROB_MOVE (or alternatively) $FILTER_EMPT (see also $MOR_GRP[n].$ROB_MOVE on this forum).
-
You could perhaps see whether the Fanuc support in ROS-Industrial could be of use here. It basically does what Jonson suggests, but you wouldn't have to start from scratch. The Karel and TP programs used there should be independent of any client connecting, so theoretically could be integrated with a Matlab client.
I'm not sure about the performance of it, but for some applications it will probably be enough.
-
Seems this is currently not possible, unfortunately.
-
are you trying to connect roboguide to an AB processor through your pc's ethernet port?Not necessarily any specific device: I'm just looking to interface with a controller in Roboguide using Ethernet/IP.
If so, I don't think roboguide is able to do this.That would be unfortunate.
-
Does anyone know whether the Ethernet/IP Adapter (option R784) is supposed to work when running in Roboguide?
As far as I know I've set it up correctly (followed the documentation), but I cannot get the Status of the Slot to change to ONLINE, or in fact to anything but OFFLINE.
Have configured DO/DI (rack 89, slot 1, start 1, range length == 16 x nr_of_words), restarted controller multiple times. No effect.
frvirtual.exe is listening on UDP 2222, but not on 44818.
-
This points to an issue with your Roboguide/OLPC install. Make sure you have the correct versions of files installed, and that all DLLs are still in the right place.
This issue can arise when one (or more) of the DLLs in the C:\path\to\fanuc\roboguide\WinOLPC\Versions\*\bin directories have been corrupted somehow.
It can be diagnosed, but in some cases a re-install of all Roboguide components may be quicker / more efficient.
-
Any version of the Karel Reference Manual, chapter "Socket Messaging" (in versions C to G, this is chapter 11), and chapter "File Input/Output Operations" (C to G: chapter 7).
Perhaps also: "Ethernet Function Operator's Manual" (B-82974).
-
Probably related, see post from !2Sharp:
Ouch. I can understand the need for keeping things in check, but this seems like a real shame.I'd say that especially in industrial robotics, old posts are worth their weight in gold, as they can often fill in the gaps for machines that are still functioning, but are no longer supported by their manufacturers (or the mfg is gone).
-
For now posting here, as this is where I've most run into it.
Has anyone else noticed that a lot of (seemingly older) posts cannot be retrieved anymore? Some examples:
Especially the first one had some info that is found nowhere else on the web (or at least, I haven't been able to find it).Is there any specific reason for these posts to be made inaccessible? Or have they really been deleted? If so, any particular reason for that?
-
As andreic already wrote, a STRING is a fundamentally different type from a REAL.
To put it simply: a REAL is a number, a single, floating point number, such as 1.234. A STRING is a sequence of characters, which cannot directly contain a floating point number, only letters (roughly. Punctuation and some special characters are also allowed).
So could the string be a number as well? I'm just trying to understand why someone would make something a string, and then convert it to a real.You can store the string representation of a number in a STRING, so the letters and punctuation characters that together make up how you would write a number down (so a '1' followed by a dot, followed by a '2', followed by a '3', etc), but that is a representation that you cannot use to do arithmetic with. For arithmetic, you need variables of types which are considered numbers, and REAL is one of those.
When a user inputs a number (lets say through the TP, or you read it from a file), it doesn't always automatically end up as a number type variable, but as a STRING. In those cases, you'll first have to convert it to a number, before you can use it with other number type variables (in a formula, or assign it to an integer register, whatever). The routines that can do this essentially interpret the string as you and I would, reading from left-to-right, gradually adding (small) values to a temporary variable (of a number type) until they've completed the conversion. They then return that temporary variable to you.
PS: confusingly, some operators you would normally use for arithmetic, such as addition (+), are defined for (compatible with) STRINGs. But to "add two strings" really means to concatenate them (stick them after each other). Placing one string after the other and returning their combination is obviously very different from a proper addition with numbers, which would return their combined value.
-
I don't know beacuse it may vary from motor to motor and from robot to robot, but it doesnt really matter, if you read 90% then you likely are in dangerTrue, but if you want to know the actual temperature it would be necessary to know the max values :).
Probably stored in the system variables then also somewhere, seeing as it is probably type and motor specific, as you say.
-
Thank you, according to FANUC support, it's the percentage of the maximum temperature that each motor can handle 0%-100%Interesting. Did they say where that info (maximum temperature) is stored?
-
State must be STARTED for a Tag, or things won't work.
-
If that is the case, and the file is not being converted --- but it is being used by the other files, how do we get that information onto the controller to be used?It is being translated, but only when it is part of another program. It's not a program in itself, so cannot be translated stand-alone, without %INCLUDE-ing it in a complete program.
So any program that includes that file (like jay showed you) can make use of those values as if they were defined in that program. Consider it a way to share those constants without actually having to copy them all over the place.
-
Hi. Is there the possibility to create indirect karel Variables? A simple example :param,param_1,param_2,i: Integer
GET_REG(1,real_flag,int_value,real_value,STATUS)
i=int_value
param=param_iIf I understand you correctly, you want to 'compose' the name of a variable at runtime, right? If so, then that is possible, with some restrictions. See the BYNAME() function.
One of the bigger restrictions is that you cannot actually do param=BYNAME(..), but you can only use it to pass values by reference to routines, so: MY_FUNC(BYNAME('prog_name', 'var_name', ..), other_var). But you can work around that by creating a small routine that just sets your variable to the value it received using BYNAME(..).
-
Older versions of roboguide had problems running Karel programs that used socket messaging. Perhaps that is what those older topics are describing. More recent versions are perfectly capable of 'simulating' socket messaging.
-
This is going to sound like a broken record, but: in the Karel manuals.