Merle

I am trying to use C function to do some calculations, but the compiler is choking on the following line: if ( IF_GT(1, RemainingCableLength, CurrentCablePosition) ) {} If I replace this line with a simple "if(1)", the function compiles just fine. I'm using the macros for all float manipulation and like I said it compiles without this line above. The error messages from the compiler is cryptic at best and not very helpful. Can anyone give me a hint as to what might be wrong?

That's irrelevant. They still have to be linearized differently for different bit count. 14 bit input has to be linearized over 16383 range and the 12 bit out has to be linearized over 4095 to use full voltage range.

Keep in mind that the analog inputs are 14 bit (0-16383) and the analog outputs are 12 bit (0-4095). So if you use the same scaling or linearization for both, it will not be 1 to 1.

As Gabriel said - how is your input scaled? Try linearizing the input over the voltage range you want. This will linearize a 14bit analog input over the 0-1000 mV range you need - setting input voltage equal to bar essentially. 2v = 2bar, 10v =10 bar

Here is the latest in case anyone else runs into this: So, after claiming otherwise for more than a week, Unitronics support is now saying that in fact ANY and ALL Modbus errors cause the master to enforce this 3 second messaging suspension. So even a -11 timeout error (or anything else) will cause this 3 second lockout and the -2 error code just reports that the master is in this suspension period. This matches the results of my testing, and I really could not understand how it could be any other way. They claim that attempting a transaction and receiving the -2 error code does not reset the 3 second suspension (although I'm not completely convinced of this - will need to try it for myself since I'm fairly sure I have results that prove otherwise). There is no indicator or flag you can use to check the state of the Master (which is a bit lacking) - the only way to check the state is to try another transaction and see if it works. They did specifically say that this suspension applying to all errors is the case when you are using serial comms (Modbus RTU), so it may well not be the case if you are using Modbus TCP. Not sure? Would be awfully nice if this stuff was properly documented in the help file ....

I've tried the same setup all the way down to 9600 baud. Performs the same - no comms errors, but same Modbus issues. My issues come down to not being able to transmit after a timeout (error -11). I know that when I get a Modbus operation error = -2, that means the slave messaging suspension is being enforced so you have to wait 3+ seconds before attempting another Master transmission. The issue is when I get a timeout error (-11) - how long a delay (if any) are you supposed to have before you try another Master transmission? Unitronics claims this 3 second suspension only happens after a -2 error, but in my testing, if I get a timeout error (-11) and try to transmit another command with the 3 seconds, it THEN causes the -2 error. This seems to indicate that ANY error causes the 3 second suspension and the -2 just reports to you that you are still within this suspension state if you try another transmission. This is of course contrary to what Unitronics support is telling me, but its the only thing that makes sense.

ok. I can certainly give it a try, but I haven't gone down that path since I am monitoring all transmissions from the Master and there is never any invalid data. And there is no slave connected to give a response so wouldn't be generating any baud issues in responses/receiving anyway.

No worries. At this point I am happy to be questioned on anything The link is terminated correctly. The baud rate I'm using is 115.2kbaud. Just to clarify, for debugging purposes and to try to understand the Modbus errors, I'm not even connected to a slave device right now. I'm just transmitting to a terminal app on a PC. I have not seen any communication errors at all - by no errors I mean no bit or byte errors. All commands that are transmitted are received at the terminal properly formatted and with correct CRC. The issue appears to be when the Modbus Master determines there is an error (either because there is no response or because the next transmission happened too quickly before the previous one has timed out - within 500ms). So , it's not so much a comms issue, but more a protocol issue I'm dealing with. I've been discussing with Unitronics support, but I have to question their responses. They are claiming that the only time there is a 3 second suspension by the Master, is when a transaction generates a -2 error code. However, when I try to send three transactions in a row, with a 1 second delay between each, it does not work. The first command times out (as expected since I am not trying to respond) and generates an error code -11 as expected. However, the second command does not transmit at all and generates an error code -2 even after waiting a full second. Since the 1 second delay between 1st and 2nd commands was not enough, this leads me to believe that the -11 timeout error also caused this 3 second suspension in the first command. If I increase the inter-command delay to 3.5 seconds it works, which again leads me to believe the 3 second suspension is being generated by the timeout even though Unitronics support says it does not. I know from the documentation that the -2 error does cause the 3 second suspension (maybe others too), but what they have been unable to tell me is what actually causes a -2 error to occur? What is the condition that generates it?

@Ausman I am using rs485 (Modbus RTU). As far as I can tell, there is no way to configure Retries or control the timing for multiple Modbus transactions. Not that I can find at least. There is a Response Time option for the Modbus Master which essentially decides how long the Master will wait (default = 500ms) for a response before it quits and generates a timeout error condition. I am using a UAC-CX-01RS4 expansion module for the PLC to give me the required RS485 interface capability. There is a single option that can be configured for this module which is the "Delay Time (ms)". There is no documentation that I can find on what this option actually does. Is it an intercharacter delay for the RS485 comms - probably?? This defaults at 0, but changing this will only slow down the transmission (probably) - you will still get the same errors if it times out or generates another error. The only way I can see right now, to make this work reliably, is you have to manually control the timing between multiple transaction to ensure there are no collisions (issuing an aperiodic operation before a previous one is finished). And also waiting the 3+ seconds when an error occurs to let the suspension expire before attempting another transmission. I'm also unsure if ANY error causes this 3 second suspension as well or is it just certain errors? Not indicated in documentation - so I have to assume any and all errors cause this suspension. It seems a bit cumbersome to have to do this. I expected (or assumed I guess) that the UniLogic Master would handle more of this for you, but I guess not.

I did try the "Aperiodic Indirect Group Trigger" but that did not work. I did not successfully try the Batch Operation - basically I was unsure how to use it based on the documentation. Whatever method I have tried, it seems to come down to anytime there is an error, the Modbus Master blocks all communications for 3 seconds. What I am trying to do now is monitor the Remote Slave Status (as you suggested) and when it is anything but 1, wait for the 3 seconds before I allow anymore communication attempts. The issue with this is of course the status does not reset on its own after the suspension, so you have to figure out when it is ok to try sending another message which will bring the status back to 1. Easy in theory, but not so easy in practice as I am finding.

@Joe Tauser I was trying to communicate with an actual slave device, which works for single commands only. If I try to send multiple commands within a relatively short period of time is when the issues appeared. Right now, in an attempt to understand the issues better, I am just sending Modbus messages to a terminal, playing with the timing and monitoring the status codes. All messages generate errors since there is no actual slave connected to provide a response. My confusion is "Do all failed messages/errors generate this 3 second suspension?" So anytime I get a status code back other than zero, do I need to wait 3+ seconds before attempting another message? Otherwise, the next message receives a status code of -2. I may be answering my own question here a bit - but the documentation is far from clear on this. I have been monitoring the Remote Slave Status and yes, it is 3 most of the time since the messages are timing out just going to the terminal. Good advice on this one. Much easier to monitor this one status than the status of each transaction. The only issue with monitoring this slave status is it does not reset after the 3 second suspension. So, you have no idea if it is ok to try again unless you use a timer to track the 3 seconds. Would be nice if this (or another) status bit reset to indicate it is good to try again. Right now, as far as I can tell, the only way to know if it is good to try again is to actually try sending another message. You could possibly get yourself in a situation where you can never transmit again if you are not waiting long enough between failures. I did try a simulator, but the couple I tried only allow a few messages through before is stops (demo mode). Haven't found a good free one. I'll look again. Thanks.

Sure I get that. I haven't elevated to Unitronics support because I just assumed there is something rather simple I am missing or doing wrong, which I thought someone could point out and put me on the right track. I am assuming the issue is with me and my understanding rather than a software issue or something, so just trying to avoid submitting support request prematurely And to be perfectly honest, I am quickly running out of time, and I thought the forum might be faster as well.

Thanks pascal. I am using Modbus RTU over a RS485 link. I understand (generally) the modbus protocol and how the addressing is handled. I can successfully send modbus messages to slave and receive responses, etc. My issue comes when trying to send multiple messages back-to-back, to perform register writes, which is required for my motor control. For single modbus messages it seems to work just fine. When testing with a terminal connected to the PLC instead of an actual slave, it seems I have to wait 3.5+seconds between modbus messages to get them to transmit (500ms Response Time setting + 3 sec Slave Message Suspension. The strange part is the Slave message Suspension should be only enforced when a transaction gets a -2 error code which I am not seeing. They are just -11 error for a timeout (since no slave connected to respond). It appears that the UniLogic Modbus Master is enforcing this 3 second suspension when it probably should not be?? I have another post whcih goes into this in more detail:

UPDATE: Ok, so I've confirmed (I think) that the first table is linked to the status of the actual modbus operation, and the second table is linked to the status of the specific modbus transaction. And if a transaction takes place, the status of the periodic/aperiodic transaction (2nd table) is updated and so is the status of the actual modbus operation (1st table) used in that transaction. I found a third status code table which is apparently also the status of the operation (like table 1), but it has an extra line (-2 = Slave Messaging Suspension). This -2 status code adds some explanation to what I am seeing but also some confusion. In my basic testing I am just sending modbus messages from the PLC to a terminal. The terminal is not providing any responses, so the transaction times out as expected (status code -11). When I look at the Transaction status it is -1 = Modbus Protocol Error, which in the table says the actual error code is stored in the Operation Status. The operation status code is -11, indicating a timeout which makes sense since the message was only received by a terminal which did not provide a response. Where the confusion comes from is, when sending messages back-to-back, I have to wait at least 3.6 seconds between failed messages. I say failed messages because they are all timing out (error -11) since there is no response. I have a 500ms Response Time configured for the Modbus master. So, the required 3.6 secs between transactions would indicate that this 3 second Slave Messaging Suspension (error code -2) is being enforced. (3 secs + 500ms Response Time + 100ms overhead = 3.6secs). So why would this be the case? Since I am not getting an error code -2, why is this 3 second suspension being enforced? Is this 3 second suspension being enforced at the Master by preventing all transmissions for 3 seconds (without reporting an error code -2) - there is no real slave connected to enforce it? If anyone can shed any light on this for me, please do. I'm about ready to give up on Modbus with this PLC Thanks.

When entering Modbus operations in the Register/Coil table there is a Status field for each operation. According to the help file, the Error Codes for this status parameter is listed below: However, when using one of the "Aperiodic Triggers", they also have a status parameter which is listed in the help file as: Can someone explain why these are different (different error codes)? And how they are supposed to be used? Is the Operation Status meant to be specific to that operation and it is updated (and tracked) each time that operation is used? And the Aperiodic Trigger status is just for that particular transaction (no matter what the operation is)?

I'm fairly new to Unlogic and Ladder Logic/PLC programming in general. I am using a PLC to control a stepper driver via Modbus and this is more of a general "best practice" question than really anything specific I suppose. I have successfully been using aperiodic register reads & writes from the PLC. However, what is the best way to handle multiple actions/operations? Ie. When you need to do several register writes in sequence to perform a certain action. I have used the "Aperiodic Indirect Group Trigger" to execute a series of register writes successfully, but this only seems to work when the order of the writes do not matter (ie. setting parameters). When using this feature, there doesn't appear to be a way to specify which operation happens in what order? Does it just use the ID number of the operation within the group and execute the operation based on that? I have not had any luck with this feature when I need to perform operations in a specific order, for example: stop the motor, change direction, maybe change speed, and restart motion. In a case such as this, I have been unsuccessful. I'm getting a Status code -11 (not even sure what that status means - timeout probably?) Is there a better way to do this? Should I just be using single operations instead of groups and use timers or something to control the execution? When I just stack multiple "Aperiodic Indirect Triggers" inline, it seems that only the first one works. I assume because the 2nd, 3rd, etc. operations try to send their command before the first is finished (strangely enough though - no errors are generated). Should I be using timers to control the operation execution? Is there a better way? if so, can someone provide an example maybe? Thank so much for any help.

I'll admit I don't have a huge amount of experience with Modbus, but all the different stepper driver controllers I have been looking at use hex for their addressing. Maybe it just happens to be the manufacturers I am using I guess?? Good tip on the excel sheet - I just might do that.

I am configuring Unilogic to communicate with a stepper driver via Modbus. When entering operations to Register read or write table, is there any way to enter the addresses in Hex? It appears that Unilogic expects all addresses as a UINT16. Most device manuals will list addresses in hex, so it means you have to convert all those hex addresses to uint16 to enter into Unilogic. I know this is not a huge deal for a few entries, but it seems very cumbersome - am I missing something here? Is there a way to change that in Unilogic settings or something?

Hello, I have a question regarding timers and I seem to be finding conflicting information during my research. If I am using an ON TIMER on a rung of my ladder logic to delay something from happening, does that timer pause the entire program execution, or does it just pause execution on that particular rung? Will the other rungs continue to execute while this timer is waiting to expire? Thanks.

ok thanks. I get the logic but would be nice to avoid the nuisance of passwords while in development mode.

In previous versions I had the VNC access set to "Enabled (no password)". However, I recently upgraded to 1.35_277 and in this version, this option is grayed out and not selectable. The only options are "Disabled" or "Enabled with strong password". Is this a feature change in the latest version or is something else going on here?

In my application the VFD and PLC are essentially in the same enclosure so conductor length is fairly short (< 2ft) . Like you @Joe Tauser, I was hoping to connect the VFD common to the 0V on the PLC as well since I want to use the VFD 10V output to power a potentiometer that is connected to the PLC analog inputs. Thanks for your replies.

Hello, I'm using a US5-x10-TA30 PLC (pnp digital outputs) to control the input lines on a Lenze VFD. The digital input lines on the VFD are 24V. In a situation like this, since both interfaces are 24v, is it normal/acceptable to connect the digital outputs of the PLC directly to the inputs of the VFD? Or should I be using relays on the PLC outputs to drive the VFD inputs? For reference, the Lenze VFD is a "I55AP222D00301K00S" (manual attached). lenze-i550-protec-Operating Instructions-21.pdf

Thank you.

Is there a document that describes the input pins on the US5-x10-TA30 in more detail? I'm looking for more info on connecting analog current (4-20mA) and voltage (0-10v) device inputs. I'm specifically wondering what input pins 22 (IOV) and 25 (I1V) are?