Your comments

If I read the question right, it sounds as if you have two j1939 modules in the system layout, both with source address property set to zero? The project check will have a warning "Ambiguous module address"

But even with this warning, the system will work. 

Incoming CAN frames are sorted to the JFIN:s, and if you have JFIN:s on both of them, you will have incoming messages to both J1939 modules in IQANdesign. 

The module will show No contact if it has a Timeout defined (always a good thing to have) , and if none of the JFIN:s located on that particular module are received withing the timeout period. 

The outgoing messages (JFOUT:s or the TSC1 channel) shouldn't have any effect on this. 

I am curious about the use of two TSC1 in this case. If you are using the TSC1 for speed control, why do you need to also send a separate speed limit? 

I have come across the need for sending TSC1 speed in combination with torque limit, but only in one application. If it is more common, it might be worth considering ways we could simplify the use of multiple TSC1. 

Another option for passing messages between CAN buses is to use an MC4x controller. 

On the MC4x -series, there is a dedicated feature that lets you set up filters for passing CAN traffic between buses. The CAN routing rules eliminates the need to set up individual channels for every CAN frame you want to repeat on the other bus, and is also more efficient with no impact on application cycle utilization. 

If it is a new system design that will go into serial production, it is also a good idea to use a modern product instead of the MD3. 

Have you considered the MD4-5 as an alternative to the MD3 ? 

In particular the new MD4-5 M19 that is more cost effective than the original MD4-5-T1E2. 

The reason the MD3 isn't available on version 6 together with the new XC4x expansions is that the MD3 is getting mature. Even though MD3 isn't in phase out yet and still have several years to live, we don't want to encourage the use of an old product in new system designs. 


One thing that would cause a "request rejected"  could be the settings for accepting remote connections: 

Possible causes depend on how the system looks like

If you for example have an MC4x and no MD4, the setting cannot be "Ask user", as there is no display. 

If you use a channel instead, e.g. an IDC to say that the park-brake is engaged, there could be something with this signal. 

Is it possible for you to file drop the video to us? Using 

With the blink code pattern 4 red 1 yellow, there are 4 more groups of yellow blinks should follow before repeating.

What software version is the MC42 running?

Thanks, I agree that it could be nice to have in the solutions library to illustrate the use of arrays. 

The only small performance improvement I can think of is to make the integer parameter for array size a constant channel. Only saves that one channel from being calculated every cycle, and has the drawback that it has to be public when it is only needed in this FG. 

Thanks. I checked and the array copy does refer to itself as intended, but as you say, when selecting it, the Qcode parser flags it up as an an error. 

The issue in the original post was solved in 6.01 (case 49327), this one will have to be fixed in a later release, probably 6.02.

On a related topic, in a post here, there is an idea about introducing a  "this" or "self" keyword. We don't have it at the moment, but I think it would give a nicer way of writing the code. 

Just to avoid confusion for other readers of this post, I changed the title of this post from "Global Scope Variables inside Libraries" to instead say public scope channels. There are no global variables in IQAN applications, a variable that you can write to is always local to a Qcode expression. 

What you meant was of course channels with public scope, when used in the main project these can  be read  in any function group in in the application. Except from within instances of external function groups. 

A problem in that existed in versions 5.00 to 5.03 was that it was possible to have a public scope channel in the main application, with the same name as a channel inside the external function. Qcode expressions in the external function that were referring to the channel with the ambiguous name would start out that referred to the name in the external. The conflicting name was only detected when re-parsing the all expressions in the entire project. 

This was solved in 5.04. 

At the same time, we took the opportunity to also limit the scope of channels in external files, to have a more well defined interface when bringing these in to the main project. 

There is some more discussion on this here:

Does the device you have on the network act as a DHCP server? 

The MD4 is a DHCP server on the Ethernet ports where SV cameras are used, this is how the assign IP addresses are assigned to the cameras. 

A separate DHCP server should never be used in combination with SV cameras, if there is a separate DHCP server it is only luck if the MD4 assigns IP addresses to the cameras before the other device does. And it can change during operation. 

For the question about IP address ranges, there is a knowledge base article that list the subnets used by IQAN masters here.  

In this it says quite generally that the following address ranges are reserved by IQAN masters:

Subnet meaning addresses from -

Subnet meaning addresses from -

On connector C4 (port B), the IP address used by the MD4 is listed in the IQANdesign user manual. 

To answer the specific question on what range the SV cameras are in, it is:

On MD4 connector C4 (port B) , SV cameras are in the range -

On MD4 connector C3 (port A) , SV cameras are in the range -

I was first confused when I saw you wrote about about using connector C4 to access the MD4 from remote. The more common usage is to have C3 for connecting IQANdesign/IQANrun, and use C4 only for cameras. 

Did you build it up the way you did so that you could leave the C3 with just a panel mount connector for local connections?