Do you agree that Epicor Needs new version/design of MES module ?
I believe they are working on one right now and will be out with the next version being released.
1 Like
Yes, I’m just not sure what a new version should look like.
Keeping in mind I like to criticize software in general but, I’m not so great at coming up with better alternatives. MES (for me) has always seemed confounding (maybe only exceeded by the Quality module). I wonder… what would really be better?
what i meant was, new manufacturing cells comes with many machine/robot/sometimes transfer mechanism software controls, no more manual transactions involved, so Epicor needs to redesign their MES module to be able to communicate with at least one software controller to read scanned JobNumber, Employee, OperationNum, AssemblySeq, etc and Start/End Activity, soon manual transactions will be superseded.
Edit:
extracting digital data from machine controllers to update Epicor MES even more efficient
I’ve always thought they could scrap everything in the current version except starting and stopping activities and start building from there.
Yes…something like this sounds like a good start.
1 Like
I support that type of thinking for sure, also things that need to be considered are PQ (Performance Quality), it needs to support FAST transaction times, it’s far too slow and clunky as it is, there are many operations out there that happen at rapid speed and the cost of collecting this vital data is high. I’m not sure how they can just pick a software controller, but maybe explore some standard platform integrations like OPC would be fantastic.
2 Likes
YES…
building a form/UI to set a path to any SQL-based machine data will be a good start, so any software controller has these type of data can be read and act up on from the MES new functionality.
We are doing some of this type of functionality on our systems. One thing I will say for us is that using an external application (Labview from NI, or Ignition from Inductive Automation) to call to Epicor via REST seems like the more logical answer. Having Epicor deliver maximum speed and flexibility for calls via REST so that whatever system the end company uses to deliver its automation can easily communicate with Epicor seems like a more reliable and functional plan. It is also a route for the best method of backwards compatibility. If your existing OT (Operations Technology) network already exists having to replace ALL of it to support an update to Epicor’s Idea of what integration should look like would be prohibitively expensive. Again, instead of Epicor trying to integrate directly it should be flopped. Epicor provides the general gateway (via REST) for OT software systems to call Epicor seems like the logical pathway. Just my 2 cents.
2 Likes
i agree with you @EarlGrei, the main issue of this approach is having a software controller UI with no ability to be customized whatsoever, it has a SQL-database sitting either on the hard drive of the machine or on a shared location that you can read from and -write to ( up to certain level)- that is all, this data is very useful if Epicor can import and act up on, Note: External BAQ is not suitable because it is not one way data transfer, what i am suggesting is to develop new triggers on the MES to deal with such situations rather than relying on manual interactions.