Jump to content

Recommended Posts

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?
Link to comment
Share on other sites

  • MVP 2023

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. 

 

  • Upvote 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • MVP 2023

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

  • Like 1
Link to comment
Share on other sites

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.

 

  • Like 1
Link to comment
Share on other sites

  • MVP 2023
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.

  • Like 1
Link to comment
Share on other sites

  • MVP 2023

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

  • Like 1
  • Haha 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...