How to control a KRC2 sequence through an HMI?

pretty much anything is possible when programmer is capable. selecting sequence to run is easy. you can even use value in variable overview, or a rotary selector switch with sufficient number of positions. the problem is when something unexpected happens and you need to recover. the less sophisticated means (like selector switch) may not be suitable for feedback and interactions. one could also provide choice using dialog or HMI etc.

What do you actually need to accomplish? How sophisticated does this "HMI" need to be?

Most industrial HMIs require a PLC to operate them -- the HMI is often just a screen for a PLC.

If you only need a selector knob and some buttons, you could wire them directly to the KRC via a DeviceNet module. But this will require programming on the robot to allow those signals to control what the robot does. For example, all KRCs come with the CELL.SRC module and support modules. Standard practice is to modify CELL.SRC as needed to allow remote selection of which programs are run.

However, there is no simple way for a KRC (You have not mentioned the KRC model, or KSS version it runs) to control a screen. You could easily set up lights to be controlled from the KRC program, but an actual screen HMI would probably require adding a PLC.

Well, a minimum-cost "HMI" could just be a selector switch and some lights, with each switch position and light labelled with a specific product name. The switch would tell the robot what to run, the light would show what's being run. It could all be controlled from the robot program.

Ditto for the reset button.

Simplest HMI is just a KRL dialog message with buttons PREV, NEXT, SELECT.

every time PREV or NEXT is pressed, display another message...

how hard is that?

if you need help, try stating things in a formal way (specification)..

what exactly is "too many"? without stating something about the magic number, nobody can guess what you have in mind. and there is a big difference between 50 and 5000000.

as i recall, KUKA HMI option for KRC2 was Iconics product called Genesys. Kuka does not offer it any more but you could try contacting Iconics.

Quote from Temp22

I planned it this way because the KRC2 doesn’t support Modbus TCP (as far as I know), and the only way to use that smart relay with the KRC2 is point-to-point. I feel like it’s a waste of resources to set up communication like this, but it’s the only solution I’ve found.

KRC2 does not support ModBus AFAIK. Bridge devices do exist: https://www.hms-networks.com/p/ab7635-f-any…dbus-tcp-server

You will probably have to devote a cluster of $INs to represent the product ID to the KRC as an x-bit number, and the same for some $OUTs for the robot to send status values to the Zelio. Which is entirely workable, as long as the Zelio can support it.

You could explore OpenShowVar, which is discussed many times in the forum archives. It's an unofficial, unsupported add-on that allows a remote computer to get access to variables in the robot via TCP/IP. I've never used it myself, but some people seem to like it quite a bit. This could bypass the entire "PLC" question, but would require trusting a piece of non-KUKA software, not to mention writing a client on whatever computer you use for your HMI.

There exist(ed) touchpanel HMI with industrial bus protocol, we have used one with profibus many years ago, at the moment I don't remember the name. Can look for it if needed.

It wasn't that cheap, nowadays most very cheap touchpanels use Modbus because this protocol is easy to implement and free to use, For all the other protocols certification and/or license fees are required, therefore they aren't that cheap as Modbus devices.

But with your approach with io module on krc, zelio plc and HMI you won't be cheaper, and you will be very restricted for amount of io. For your needs you will need a big amount of io, think zelio plc is way too small.

protocol bridge translates one protocol to another. this can be handy in some cases but i try to avoid them since they still add to hardware cost and require familiarization and configuration.

OpenShowVar is a client... it can talk to KRC through a proxy server (KukaVarProxy). this is using Ethernet communication but... this has nothing to do with Ethernet/IP.

you still did not provide any clarification what you want to do, how many different programs you need to choose from and what would be most suitable user interface.

Quote from Temp22

Thanks to your suggestion, I might be able to eliminate the entire I/O module system of the robot and use the Smart Relay to manage the I/Os and the HMI, but I’m not sure if it will work. What limitations could there be in using this bridge?

Well, from the KRC side, it would just be more $INs and $OUTs -- the Bridge would look like just another I/O module to the KRC, simply with a large number of bytes.

On the HMI, it would depend on the HMI you buy, but generally the ModBus HMIs I've seen also act like simple I/O devices -- they "read" the Bridge outputs, and write to the Bridge inputs. Then the bridge simply passes those bytes between the DN and ModBus.

Quote from Temp22

That’s interesting to know. I’ve only come across posts mentioning Kukavarproxy, but they don’t talk about that. Could it be that a KUKA Ethernet/IP card is needed to use OpenShowVar?

EIP? No. Short version: KRC runs two OSs in parallel -- KSS (built on VxWorks) and Windows. Windows handles the file system and the user interface (KUKA HMI) on the KCP. KSS runs all the realtime, I/O, motion control, etc. The two OSs communicate through a virtual network port, as if they were running on separate computers -- this is why messing with KRC network settings in Windows is dangerous, as you can brick the KRC by screwing with the wrong NIC.

The physical NIC on the KRC (on a KRC2 ed2005, it should be on the motherboard, though it was on the MFC cards on older KRCs) is "owned" by Windows. You can use that for file transfers, but it can't talk to KSS, and KSS can't talk to that NIC.

Technically, it's possible to write programs that run in the Windows half of the KRC that can reach over the virtual network and read/write to variables in KSS, but KUKA keeps the information about how to do that pretty confidential. Doing it wrong can crash the OSs.

The different ShowVars programs create a network bridge between the physical NIC and the virtual one, and allow you to write Windows programs that can read/write variables in KSS. But they're not officially supported by anyone.

Quote from Temp22

Are you saying that instead of a 1-bit input, it will be 2 bytes?

No. One bit is one bit. The bridge is usually configurable -- could be set up as a 8-byte device, or a 80-byte device. But one bit on the bridge will be one bit on the KRC.

At the bus allocation level, a byte is the smallest unit that can be allocated. So if you need 9 bits of I/O (say, $OUT[1] - $OUT[9]), you have to allocate 2 full bytes in IOSYS ($OUT[1] to $OUT[16]).

Quote from Temp22

how are the Modbus devices mapped in the KRC? Does the bridge represent all the other devices as one?

Usually, yes. Depends on which bridge you buy, but the ones I've used appear as a slave device with one big block of I/O bytes to the KRC. Then the Bridge acts as a Master to however-many slave devices on the other bus.

So the KRC might see the Bridge as $IN[1] - $IN[64], but the Bridge has been configured such that the Style Selection is $IN[1] - $IN[16], and the start/stop/whatever buttons are on $IN[25] - $IN[32], and the rest are spares for future expansion.

Quote from Temp22

I had read something like that in another post where they said that "normal" NICs communicate with Windows first, but KUKA NICs communicate directly with the KSS. To communicate more securely with the robot via Ethernet, would I need to buy the KUKA card? This way, I could avoid using a ShowVar program?

Not really, since KSS does not expose internal variables to the KUKA NIC. ShowVar is a "backdoor" using access that KSS already includes, but KUKA never publically documented.

all that HMI does is read /write controller data...

assuming you have the data, you should be able to use it. and in absence of suitable HMI, you can simulate it. for example use integer such as I[1] . you can change the value from Variable monitor or from Variable/Counter menu.

or you can create own variable if you like....

the point is that you should be able to write some program that allows calling one program according to the variable value. and if the value changes, another program would be called etc.

an example of this is CELL.SRC which does the same thing using PGNO. at any rate, you need to determine how many different programs you want to be able to choose from.

btw using CELL.SRC is not a bad idea regardless what kind of "PLC" you intend to use (rhardware PLC, or smart relay or arduino or RaspberryPI or own submit interpreter....).. in simplest form you can create the interface using I/Os. I/Os are the way robot uses to interact with external world, if your robot has some physical I/Os, then you can wire them to bunch of buttons and lights (or your smart relay).

using fieldbus (DeviceNet or Ethernet/IP or whatever) communicates state of the I/Os using network. type of fieldbus is irrelevant, and if your PLC and KRC do not speak same fieldbus, you can insert suitable bridge or gateway so that it acts as translator. this alone will cost on the order of $1k just for the hardware. but you still need the rest of the system. and choosing correct bridge/gateway requires some knowledge about fieldbusses as well as knowing fieldbus capabilities of the two nodes that bridge is to connect. if you do not know this, there is a good chance that you would choose wrong type of bridge.

so far i do not have feeling that you can do this. you are still beating around the bush and grappling with terms and KRC architecture. so you are still far from making decision... when you do not know how to do something, i would recommend to choose path that others have used so that you can get support. if you pick path that includes a unicorn, you will be all alone.

if you want concrete advice, make sure to share some DETAILS... so far you could not put a number on ANYTHING...

how many programs you want to be able to choose from. that will determine number of bits for program number. that will dictate what connection type can be used.

what is the exact smartRelay model that you have or plan to use? what is the HMI that you are thinking of? because if you are thinking of something like this:

Schneider Electric's Zelio & HMI Starter Kit VJDSTKXBTNSR2-all you need to get started!

Schneider Electric have now added a direct link between the 24V Zelio Logic Controllers and Magelis (XBTN41*, XBTR41*, & XBTRT51*) graphic display terminals.…

www.voltimum.ie

you are already on a wrong path.

first of all number of I/Os is puny. so if bridge/gateway option does not pan out you are stuck (not enough of I/Os to hardwire it). if at least your smartRelay had some 40 or 64 I/Os you would have an option to dedicate enough of I/Os to hardwire signals to KRC (and you would need to add I/Os to your KRC).. and programming/troubleshooting on smartRelay is going to be royal PITA. the HMI is puny as well. good luck with displaying pull down list with 50 or 500 entries and then trying to select one specific entry. it would be pressing arrow keys mny many times to reach correct item, it is no better than using dialog.

suppose you pick some full size HMI (any brand).... say 17" industrial HMI, what type of control would you use to select program there? you said it would be many programs to choose from... so pull down list? how long is the list? how often will list change? because industrial HMIs also have some limitations - one of them is type of controls you can place on screens.

if the list is really long, i would like to see custom solution:

a) fresh list of available programs - sorted in suitable way (A->Z, Z->A, last used etc.)

b) possibly only consider specific programs (perhaps only from a specific folder, or ones tagged with specific attribute)

c) have option of filtering results to narrow down choices before picking one item from the list. ideally list should be reduced/refreshed with every letter typed in.