When I updated to IQAN 5.04, I four new errors that popped up that seemed to be related to the fact that it can't use a date data type in the memorizing channel.  This exact same program works in IQAN 5.03.

Dear could you add a enable parameter on all CanBus function. If we have some option material, it is easy to desactivate some CanBus function.

In generale it could nice to add Enable Parameter on all function.

Regards

I have 2 x MD3's that previously had been used separately on different machines with an application that had the displays configured as address 0. I now wish to connect them to the same diagnostic bus and install new application software with one as address 0 and the other as address 3. I seem unable to change either of the displays from address 0 to 3. I have the correct ID tags inserted, tried safe mode, tried unplugging one of the displays, tried changing the display (just in case it was faulty), the resistance of the ID tags are correct. Still cant work it out, can anyone help?!

If i unplug one of the displays i can send an application that has a single display configured as address 3, but even with address 3 tag inserted in the rear of the screen it comes up with wrong ID tag on the display. Appears to be the same in IQAN design 3, 4, & 5.

I'm working on my first project using a MC42, our master already has an application loaded.

I'm using design 5, when trying to communicate via Ethernet, my LAN identifies the connection as unidentified.

When I use Get project, no modules are discovered. 

Can any one help me with this issue?

I have a memory channel with a range of 0 to 9,999,999. I have it in an adjust group with a step size of 1608. (The channel is meters and 1608 is 1 mile.) When using the adjust tool in runtime, the tool will not allow the value to increase above 99999.99.

I am working on a program that is for multiple machines with multiple different default values. We currently use a FP with a run mode that has multiple states to create default values for each state. The issue I have is where each machine has different defaults I have to duplicate this for each machine. 

It would be nice if the Default Values could be dynamically changed. I have a few different workarounds, but this seems like a simple request that I am sure others have run into?

Can CANOpen 11bit and 29bit ID on same generic bus?

I was hoping to get some feedback on an error I am encountering. One of our VREF channels is acting up an our MC43 controller.  As soon as VBB is greater than 14.0 volts, the Vref goes immediately to 0.0v and throws an error. If VBB drops back down below 14v, the error goes away. The only thing on this Vref is a position sensor (500-4500mv) going into a VIN.  Any thoughts on what could be causing this? I'm happy to provide more information if necessary, but I'm not sure what else would be of help. 

Regards,

-Chris

If a customer purchases a license for Design 5 (only, not developer suite), should the license key work for creative studio 4, 3, 2?

He needs Design functionality in old programs as well.

We have 3 master modules connected according to image above...

We send a P-brake apply command according to the image above. One goes out through the APPO_PbrakeRelease channel supposedly through the "Master" CAN-connection. The other goes out as a Generic CAN-signal through the "Generic" CAN-connection...

The APPO_PbrakeRelease channel is configured as shown in the image above. 1s transmission rate or on change.

On the receiving side, the input is controlling a digital output. The value of this digital output is also transmitted on the "Generic" bus. In other words, on the "Generic" bus we can see the value that should be sent out through the APPO_PbrakeRelease channel as well as the value that is received on the APPO_PbrakeRelease channel...

The problem is, occasionally we see a glitch as the one above. The value that is sent is constantly HIGH, while the value received goes low for exactly 1s and then goes high again. We have seen this for other digital "Application OUTPUT/INPUT" channels as well.

The fact that the time (1s) perfectly matches the outgoing transmission rate configured at the sender leads to the conclusions that one CAN transmission is corrupted and that the following transmission, 1s later, is correct and again sets the correct value. If it had been an actual change of the input signal, then I assume the APPO_PbrakeRelease signal would have been sent again as soon as the input changed back again?

Also, that the "Generic" CAN-transmissions which has a transmission rate of 20ms, doesn't show any incorrect values limits the error to the "Master" bus only. We have so far not seen any similar behavior on the "Generic" bus.

The "Generic" bus is connected to CAN-bus logging device that records every CAN-bus message transmitted without any filtering or "sampling interval". So, if we can't see any change of the signal here, then no such signal has been sent on the bus.

Is it a known problem "Application OUTPUT/INPUT" signals can get corrupted? And more importantly, how does one handle this?