Your comments

Thanks Michael. As you figured, the specific voltage on ADDR_L that causes the MC4x to bypass its application isn't 3 V (it's a copy paste error from another master). 

If the module would have had the application bypassed, it would have blinked "application not loaded", 1 long yellow followed by 1 short yellow. 

I am confused by the problem description and the resolution. 

The system mismatch blink (3:3)  would come if the MC4 doesn't have the exact same version of the project as the other masters. It would make sense if that module was offline when the rest of the system was updated.

For a reverse-feed, I would have expected to see 4:2:1:1:1 (4 red and 2 yellow, followed 1 yellow 3 times) 

If the MC43 didn't start its application due to reverse feed, then I would have expected that there should have been a "no reply" dialog during sending. 

I just tried it and got the same problem. Seems as if the script action Execute doesn't insert the variable value as it should.

You have the right syntax, so this must be a bug. 


I took the liberty of changing the title from "MD4 Hangs to change pages" to "MD4 takes time to change pages"


As David wrote, the amount of graphics (display controls) on the page you enter will influence this.

You should start by counting how many display controls you have on this page. Perhaps it is possible to reduce it?


Another aspect is the cycle utilization and cycle time. With a higher cycle utilization, more time is needed for calculating the real-time application, leaving less time to draw the graphics.

If possible, increase the cycle time. 

Frank,

Thanks. I think I understand why this happens now.  When you select Ethernet in IQANdesign/IQANrun , it is normally using the  UDP protocol, which has better performance than TCP/IP. But UDP has the drawback that packages can be lost, especially when there is lots of traffic on the network. Normally this is not an issue, it is handled by the higher-layer protocols between IQANdesign/IQANrun and the master, but I think you have come across a gap here, when starting a large measurement on many components. 

There is a workaround, by using the tab "Static modules" instead of "Discovered modules", you can force IQANdesign/IQANrun to use TCP/IP. I believe this should solve the issue you are having. 

To use this workaround, you'd need to write down the IP address of the MD4, switch it off so that it doesn't show up under discovered modules, enter the IP address under "Static modules", start the module (hoping that it gets the same IP address), and then connect. 


The built-in TSC1 channel for speed control sets the torque to 0xFF.


I see you are using the Kohler engine, they have a special requirement to set torque to 100 when using speed control. 

To implement this in IQAN, you can build up the TSC1 message using JPOUT and JFOUT. 


See attached example: 

TSC1 speed request kohler.ids4

Kevin,

For the size of function group you have with 677 components, I am suspecting that you might be hitting the limit for number of items you can stream a measurement on at the same time. Do you get the "measure terminated" dialog?


The limit is 999 items, but I just realized the component count you see in the lower right corner will only count function groups as one component. 

Haven't been able to reproduce anything like this. But I looked at the original post again and saw that it said: 

"Most of channels stay in grey color, and not showing its status."



Actually, they gray box is an indication of a status also. 


The gray box can indicate any of the following statuses:

-unknown

-not evaluated

-disabled


To see the full status, either hover with the mouse over the channel to bring up the tool-tip hint, or drag the channel to the "multimeter" measure window:


Unknown would be what you would for example see if there are different versions of the project file in IQANdesign and in the master, and the project file open in IQANdesign contain channels that aren't in the version of the project file that was sent to the master. 

Not evaluated is for channels that haven't been calculated yet. For example, incoming CAN frames that haven't yet been recieved. 

Disabled is for channels that are on a disabled expansion or in a disabled function group. 

The channels in can IQANdesign only have the value types 32-bit real and 32 bit singed integer. 

Even when you set a GPOUT type to unsigned integer, the channel value in IQANdesign will still be a 32-bit signed. 


If you have the GPOUT set to e.g. 2-bytes unsigned and feed it a negative number, the check for calculation overflow will detect it, give an error status on the channel and set it to zero. 

But when the output length is also 4 bytes value, the GPOUT check for calculation overflow won't catch this, so the value will be sent out without change. 

Which means the modules listening on the bus can read the 32-bit value and interpret it as intended. 


(on a GPIN, you'll get a project check warning if you try to set unsigned 32-bit)


Also see feature request: 

https://forum.iqan.se/communities/1/topics/387-handling-huge-unsigned-int32-numbers