Yes (it uses the same control engine).
Don’t know (Have not had the chance to do any bench marking with EPIC as yet)
Sort of (its a faster processor than the PAC’s, so it will still delay, but less).
Oh ok. A long time ago, I thought that Bryce explained that the problem was the architecture of the CPU, but I guess as a result they had to program around the new architecture of the CF32 and therefore it’s actually built into the platform code?
Ok, well this might be a bit off the subject, but here goes. Feel free to move it.
I have this project to bid where I am migrating a Joe White Malting Machine…which was built in your backyard somewhere around '96-'98 (actually Sumwerlakes Parade Ballajura, WA on last rev).
Anyway I am migrating the B100/B200’s to E1’s and E2 and then I was going to S1 it and use PPPro. The problem is that although they did an excellent job and the code is really nice and clean and notated and documented, there are 53 charts, and approx. 500 uses of the stop, start, continue, pause charts commands. That would not be the worst of it except the sequence of the strategy has no single main chart, so figuring out the sequence might be a lot of work.
Here is the quandary, I know that these chart commands may or may not be a problem, it really depends on how often they were used, etc, etc. If it only delays the operation of the machine here and there by 100ms, so what. However, if they used the commands in the right way, it could cause some strange operations if the chart queue gets filled up and then starts doing who knows what.
Do I just migrate the hardware to an S1, fire it up and see what happens at customer site (out of town) or, use SoftPac to brute force it, or go through the whole thing with an Excel spreadsheet and make a map of the sequence and then reassemble all the parts in the correct sequence in maybe a quarter of the charts?
I had another thought, make a main chart that provides the sequence control and use bits or integers in that chart in place of the start/stop/and continue commands?
Does SoftPac have exactly the same chart switch issue as S1, and would the 100 fold speed increase solve the problem or make it worse?
Yeah, nah… I had a really (really really) bad experience with this sort of coding ‘efficiently’ about 5 years ago and am still triggered when I hear about doing it that way… but, hey, Barrett, if you can keep track of it and document it clearly, more power to you.
+Ok, I agree I agree…readability is a good point, the only reason for the 64 bit is I can look at the whole system with one command and can make a loop to look at each status, but I agree, the individuals would be better. And yes, this might be harder than anyone might dream…it’s all mute at this point since I found where they are using TPO on the B100’s so the E1’s don’t support that. To get around that without switching EB’s I would have to rewrite those portions and then hope there aren’t other features being used…I see that the more main charts are sequential and probably have to run for a long time before going to the next chart.
I could just leave the LCSX in place and update Opto Display to Pac Display, but I have seem some issues with that, not as clean as I would like.
I think I may have to switch to S1 or SoftPac (no room to mount Epic unless I switch all) and leave the B100’s and B200 in place. It’s not like you can’t find those if you have to…and then see if this thing works as is, then go after the rest if any issues arise.
Whoever wrote this strategy, knew what they were doing, and also knew the process really well, because their had to be a whole lot of development work to get it to this place.
I think I’ll run S1 and see if problems arise, if that doesn’t work, then I’ll run SoftPac. I have no control of the PC they will use and any config or software they plan on using on it, so might be better off using S1 if it will cut the mustard, otherwise, fixing it the right way could be a bit more expensive.