Using MD4-7 as "Optional" diagnositcs tool on multiple MC42's
We have built identical machine, running identical software on MC42's, with the idea of only having one MD4-7 display between these machines as a diagnostics/adjustment tool that is configured as "optional". This would allow for when connecting the display to the MC42, the technician will then be able to interface with the MC42 to adjust parameters.
Also I use the MD4-7 as a programming tool to upload new software onto the machines VIA the display's ethernet port... But what I have encountered is after uploading all the software on both the machines and then plug the display back into the other machine it give a "NO contact MC42" error. Which means I have to upload the software again with the display in place to get contact to that MC42. So each time I want to use the display to configure the other machine I have to do a software upload again from the laptop.
In theory I can't see why this wouldn't work? the display does not store any values, it only displays the parameters that is stored on the MC42's which allows the to technician to adjust those parameters on the MC42 through the MD4-7 display.
I have also tried to upload the software separately on the display only (as an incomplete system), but then it gives "no Contact" error on both machines until I upload the software again with the display in place.
There must be a way to trick the display to think it is connected to the same machine each time it gets swapped around between the 2 machines.
Customer support service by UserEcho
I think this is caused because you're using a multi-master system?
There's probably some sort of communication with serial number or similar.
In order to achieve what you describe will probably take a different approach.
We do something similar in the machines we build, we have a couple of standalone controllers, each running an application of their own. (so if 1 fails, the others will just resume operation).
With an MD4-5 (also standalone) communicating with each separate controller, retrieving parameters and the ability to change parameters using only the display by sending J1939 messages.
We do this by using MEM channels, so we can change the parameters either using the display, or just connecting a service-laptop and using IqanRun.
However, this method is very time-consuming and (possibly) over-complicated.
I think there is an example in the solution library showing how you can use MEM channels as parameters.
Great answer Barth, makes perfect sense...
I will definitely take this approach when I have to do something like this again with IQAN. Otherwise I will have to rework quite a few things on these current machines, like wiring alterations to make provision for an additional ethernet port and also to put everything in can frames and splitting up and separating the program is not something I would like to endeavor at this very moment due to the fact that the machines are about to get handed over to the end user at any moment now, so we will just have to deal with dragging a laptop along each time we need to adjust parameters (which won't be too often at all if the machines are set up correctly).
The solution of using J1939 or even generic CAN is absolutely very clear and this is basically the way I normally go about when working with other brands of controllers and displays that has to communicate via CANbus.
I was just hoping to efficiently utilize the multi-master method with all its features by using the display as "optional" and making it interchangeable, but this clearly does not work as hoped.
As you mentioned, it might be some sort of serial number verification or something that makes it not possible to swap hardware on a multi-master system...
I'm also actually quite glad to have discovered this now and not in a possible scenario where if per say an IQAN display or controller failed in the field (which hasn't happened yet thankfully), if this had to happen I would have then probably recreated a mock up of that "multi-master"system on my desk to upload the software and do a functionality test and only send away the component that actually failed on that machine. Which in theory sounds as if it would work, but will in fact not...
This actually brings me to shocking realization! What will I do if I ever come across a scenario where I only have to replace one component out of a multi-master system? We have quite a few machine running multi-master IQAN system out there in Africa at the moment, but some machines are on places that is not that easy to access like for instance diamond mines, where it really is an issue to get access as a "normal" person and then to bring laptops and other components into the mine requires special clearance and a lot of paperwork and also not to mention that it consumes a lot of time travelling and simply just waiting...
Normally on other CAN based systems I do as mentioned above where I replicate the system and do a function test and then only ship off the component that needs replacement which then gets fitted on site by someone on the mine (just plug and play usually). This person on the mine is usually a "hands on" technical person which does not use any form of computer, so to instruct that person or any other person on the mine to do a software install on a mining machine will raise a lot of eyebrows and will probably require specific training with certification before that person may be allowed to even switch on the computer near a machine.
This is not something I have considered of being an issue up until now...
Does anyone know if there is a possible solution for this?
We anticipated this problem, so we have set up our systems using only stand-alone controllers.
Now, when a controller fails, only part of the machine won't function, and the other controllers resume their normal operation.
the application can be loaded separately on a controller and be installed by an electrician.
without the need of any extra diagnostics tooling.
Have you considered fitting G11 and then just using an Ipad as your optional diagnostic/adjust tool ?
In a multi-master system, the Project checksum is used to identify that all master modules in the system belong to the exact same version. To use the optional MD4, you must ensure that it runs the exact same version of your application as the MC42.
Project checksum is a unique identifier for this exact version of the project file. It is used at system startup, together with project ID, to verify that all master modules in a system originates from the exact same version of the project file.
Barth, I will definitely as a rule of thumb separate the controllers from now on when starting a new project... It is just the machines that are already running on the mines as multi-master systems that is a bit worrying.
Nick, Yes, we have been using the G11 on a few of our projects, but not interfacing via IPAD yet. I might just have to give it a try.
Gustav, I'm not sure if I understand correctly, I do use exactly the same project version with exactly the same hardware setup (I only swap and share 1 display between the 2 controllers)...So the Project Checksum should be the same then if I upload the same project on both machines, I can't see that changing the project ID would really do anything or am I just missing the point here?
Thanks for all the feedback.
Any change you make in IQANdesign to the project file will alter the project checksum, even if you for example only move a channel one pixel in the application view.
One good way of making sure there is no change is to use IQANrun when sending, then you can be sure that you won't alter a project file by mistake.
Not sure if you meant that you changed Project ID? That is a big change to the project file. This should normally be avoided, if you change Project ID the machine will no longer recognize previous settings.
Thank you for clearing that up Gustav,
There are no changes that I am aware of when uploading software, I 1st upload to the one display then upload to the second one right after that... But I have not yet tried IQanrun to upload... Will definitely give that a go.
Thank you very much