Marcelo Orlandin Posted April 21, 2020 Report Posted April 21, 2020 Hello, I have an application running at one of my customers, which there is a V1040 PLC communicating via Canbus with 7 EX-RC1 nodes of which two modules have been installed recently. Each EX-RC1 has a couple of expansion modules connected to it and exchange digital and/or analog data with the PLC. I have followed all the instructions on how to install and configure all the devices, and my application was working fine with 5 EX-RC1 nodes. The problem is, when I installed the others two nodes, my application started behaving strangely: The data (only MI's) coming from two specific nodes (the nodes with analog expansion modules) started oscillating between right and ramdom values. However, the communication among nodes was apparently ok, as I could notice it by watching the values of MI Status Message (between 0 and 1); The problem only stops if I disable the Unican send blocks that are sending analog input values. Moreover, this oscillattion only happens on my PLC. If I get online on the EX-RC1, I do not observe any oscillattion; Do you guys have any idea of what is going on?
MVP 2023 Joe Tauser Posted April 21, 2020 MVP 2023 Report Posted April 21, 2020 UniCAN with that many nodes can be a bit like walking a tightrope trying to keep all your data locations straight. You probably have an issue with the destination addresses in the UniCAN blocks in your RC1s. Post your programs and we'll have a look. Joe T. 1
Marcelo Orlandin Posted April 21, 2020 Author Report Posted April 21, 2020 Hi Joe Thanks for replying me... I'm attaching the main program and the two EX-RC1 programs that I mentioned on my post. PLC node 1.vlp RC1 node 2.vlp RC1 node 3.vlp
Marcelo Orlandin Posted April 21, 2020 Author Report Posted April 21, 2020 Nodes 2 and 3 are the ones that have been oscillating. It is important to say that they worked fine before installing nodes 7 and 8... The program is the same and I've just checked and haven't found any conflict of registers among nodes 2, 3, 7 and 8
MVP 2023 kratmel Posted April 21, 2020 MVP 2023 Report Posted April 21, 2020 PLC node 1 need password... By the way. As i see - your send commands via UNICAN work with the system bit timer activation. If time for transmission information is to short - you cannot read some nodes. Maybe you must program sequence for read each node with some time gap or read next node if information from previos is sended to main PLC. 1
Marcelo Orlandin Posted April 22, 2020 Author Report Posted April 22, 2020 12 hours ago, kratmel said: PLC node 1 need password... Forgot that.... here it is: EMK1268 12 hours ago, kratmel said: Maybe you must program sequence for read each node with some time gap or read next node if i nformation from previos is sended to main PLC. Although this may improve communication performance, I don't see why this would actually solve my problem... Just to give you guys more details about my problem... Nodes 2 and 3 were working fine when my network had 5 RC1 nodes. Right after installing two more nodes (nodes 7 and 8), the data coming from nodes 2 and 3 started oscillating. The communication among all nodes were still good and all nodes kept working normally, except for nodes 2 and 3. At first I had thought the oscillation problem happened because of electrical noise... but now I've been thinking it is related to analog signals somehow. Since I disabled the UniCan sending blocks which were sending MI's from my analog expansion modules, the problem has stopped. It is important to say that only nodes 2 and 3 send data provided by analog inputs. I just checked the programs for nodes 7 and 8, if they write data into the same MI's as nodes 2 and 3, and I haven't found any issue... I'm also attaching programs for nodes 7 and 8 to help you... maybe you find something I'm not seeing.... RC1 node 7.vlp RC1 node 8.vlp
MVP 2023 Ausman Posted April 22, 2020 MVP 2023 Report Posted April 22, 2020 Edit... for some reason I had this as being a Unistream issue. As I have said before on the forum, I'm only a Vision man. But some thoughts that might be relevant...... Initially, I'm with Kratmel in that you may need more time. It could even be a buffer not clearing completely issue. As well, as an experiment, can you change the node numbers around to see what happens? Does the error still happen on 2 & 3, or follow the physical connection? On 4/22/2020 at 2:53 AM, Marcelo Orlandin said: If I get online on the EX-RC1, I do not observe any oscillattion This would indicate that the values are mainly correct and the inherent stream delays in being online is not showing them. cheers, Aus 1
AlexUT Posted April 22, 2020 Report Posted April 22, 2020 After reviewing your projects found, that you use normal closed SB 7 to activate all UniCAN Send at all projects. All scans at first 50 of 100 msec all RC1s and PLC are sending UniCAN packets. The only stopper is SB 202. So you flooding communication line by useless packets. It is recommended to replace SB 7 by SB 15, which is active for 1 scan each 100 msec. Hope this solve all your problems. B.R. 1
MVP 2023 kratmel Posted April 22, 2020 MVP 2023 Report Posted April 22, 2020 20 minutes ago, AlexUT said: So you flooding communication line by useless packets. This is maybe main problem. You can use simple increment counter from 0 to (N-1) --- N -node number. This counter must be incremented by SB timer. Then use simple comparators for enable command for nodes reading step by step. But you must realase in all nodes "send on request" communication. 1
Marcelo Orlandin Posted April 23, 2020 Author Report Posted April 23, 2020 You were right guys Apparently my Canbus network was overloaded.... After considering some time among packets, the oscillation stopped Thank you all for the support
MVP 2023 Ausman Posted April 23, 2020 MVP 2023 Report Posted April 23, 2020 Glad it's solved. Just FYI, (I've said this before in other posts) but I have had instances where in trying to make things fast, I progressively lower Canbus comms times back to what seems to be working ok for an entire day, only for them to fall over a few days later. Adding just a few scans into my call times fixes the issue. I have found that for anything comms-wise, you need to allow a few scans for full buffer clearance, even though the system may say that it is finished. I surmised that the comms would eventually fall over due to a slow "build-up" in the buffer that eventually overloaded things. Or perhaps a glichey (?) read added in more numbers than normal? Or the data fairies waved their mean and nasty wand✨ at just the right time as they flew past going to Joe's place to share a cigar! cheers, Aus 1 1
Marcelo Orlandin Posted April 23, 2020 Author Report Posted April 23, 2020 25 minutes ago, Ausman said: Or the data fairies waved their mean and nasty wand✨ at just the right time as they flew past going to Joe's place to share a cigar! 🤣🤣🤣
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now