Damian

Ash ................. Thanks a bunch. that is great information! I guess though I am also dissapointed that they did the USB that way. I have been waiting for the USB connection for download largely because of a desired speed benefit. It is like getting a chocolate chip cookie without the chocolate chips.. thanks, Damian

Yup

Thank you for the feedback. It's sounds as if something specific to my computer is causing the Visilogic issues.

Emil, Will downloading over Ethernet be noticebly fast than downloading over USB to the V1040?

Upate ....................... I'm starting to suspect this is an issue with 9.3 not playing well with my Windows 7 64bit machine. I put 9.3 on my old laptop and it functions normal. The previous version worked fine on my 64 bit machine, so that is strange. Anyone else having issues with speed of visilogic 9.3 on a 64 bit machine Windows 7 Ultimiate?

I just recently bumped up to ver 9.3. Everything is painfully slow. Is it just me or is there something wrong with this build? It is so slow I can't get anything done.

Hi Simon, Thanks for the lesson. I have brought up the point to the customer that the color screen may actually be better than the monochrome backlit screen they have been using. It may simply be a case of not knowing any better. It sounds as though no matter what we use, we will have to expect some small amount of light contamination. I am going to try and get them to be more specific regarding what wavelengths they are most concerned about. Thanks again, Damian

Sorry, wasn't finished typing. You also bring up another very good point I didn't consider. The backlight itself may be a source of different wavelengths as well. I like your idea of say restricting myself to red. If I do restrict myself to a certain color, am I assured that only the RED emitters are operating, and NOT some tiny percentage of the blues and greens?

Hi Emil, Thank you for the quick response. I agree, true what light is a combination of all the wavelengths, but it was why impression that white LEDs were manufactured to a very specific narrow band of Yellow and Blue that fools the human eye.

I have a potential application for a V1040, however the customers application is in a dark room making a film product that may be susceptiuble to pre-exposure if exposed to certain wavelengths of light. They use old monochrome screens (black and white) and that seems to be OK for them. They are insisting on a minimum 10" screen. Is their anyway to put the 1040 in black and white mode? If I restrict myself to black and white HMI objects, I am curious as to what whter the new LED screens arne't actually creating white by mixing all wavelengths. Any advise?

Most common causes of load cell fluctuations are electrical noise and mechanical stiction. You should hang a scope probe off your bridge get an idea where the fluctuations are coming from. Are your fluctionations seen to large time spans or short time spans? You may have to experiment with your grounding and shielding, and try terminating at both ends, or one or the other. What power supply are you using? Power quality issues can also work their way into the load cell readings.

Hi Emil, You have nothing to appologize for. I like the fact that your direct and blunt and not afraid to speak your mind. I enjoy this forum, and you have played a key role in making it what it is. I think of it almost as a "Hitchhikers Guide to the Unitronics". I very rarely run into a problem that I have to ask for help with, and this is because more often than not the answers lie somewhere here in this or the old forum. You are an asset to the company. Please don't ever feel you need to choose your word's carefully with me. I tend to forget that the EX-A2X exists. Looking back at what you wrote, it was very clear you were talking about this, so the mis-understanding was all on my end. So for that I offer you my appology. I understand the position Unitronics has taken regarding not publishing the specs on the cable. I don't agree with it but I do understand. Based on my experience, people are going to do it anyway. So you are better to give them the info and better their chances of getting it right as opposed to "winging it". You will never be able to stop customers from doing "dumb" things. Your only recourse I think is to keep things as simple and make things as robust as possible while still fitting into the economic framework your targetting. Keep up the good work! Damian

Hi Emil, I sympathize with you when it comes to people coming to you with their problems. I started out in tech support, and as an integrator that role never really vanishes. The vast majority of the time it was quite simply the customer's fault and rarely a legitimate issue with the equipment. Either they didn't read the documentation, didn't follow instructions, or simply were not qualified to be doing what they were doing. However ...... if everything went perfect and nobody ever did anything wrong......... If customers didn't need help, then your job, as it exists right now, would not exist. It is a common for me to hear maintenance personnel from various companies I visit complain when a machine breaks. It makes me wonder why they think they were hired in the first place. I do take exception to the assertion that what I have said, and the cables that I have made for myself are "wrong" or are somehow lacking in quality. On what basis do you make this claim? You haven't had to field any calls from me on this, and you haven't seen what I have made. If you would like, substitute the word "right" with "recommended". I have not used the newer EX-A2X expansion module yet. Perhaps the cable for that is "fancier" than the simple shielded cat5e cable that came with EX-A1. I don't know, so I can't speak to it. To a larger degree, I think it is worth asking the question of "why are we making a simple expansion IO module that requires a fancy cable to work properly in the first place". I look at all the other technology we utilize (Profibus, Ethernet, CAN, etc.) Why wasn't the expansion comms done with something more inherently robust? I use other bus systems that are just as fast as the expansion comms that utilize simple un-shielded twisted pair wire. I think there is something fundamentally wrong with the idea of designing something involving communication to a remotely mounted device that doesn't allow you to "cut to length" the cable that you need. From a practical standpoint, when we are first designing systems and ordering material, we rarely know beforehand exactly how long cables will need to be. So by your recommendation, I always have to choose between possibly ordering a cable that is too short, or possibly one that is too long so that I have to find a place to "hide" the excess loop of cable. Or as a third option, I can wait until after the system is built, and then put everything on hold for a few weeks while Unitronics is making my custom length cable. I have also not instructed or taught others to do anything wrong. Everyone else can make their own decisions on what their capabilities are and what they feel comfortable doing. For this application, I would not recommend an expansion cable of any kind, no matter who made it. They are better off using CAN at that distance. The key to minimizing calls to support and trouble with the product is to provide the customer with the tools necessary to do things properly. Rather than insisting on making everyone’s cables for them, it would be far better to post a drawing in your documentation library that instructs people on how to do it themselves properly. D

Hi Joe, I agree. If you need a lot of IO at that location, the EX-RC1 makes good sense. If you only need a handful of IO it can sometimes be more cost effective going with the likes of a V120-22-RC6, which is cheaper than getting a EX-RC1 and an IO-DI8-R08 for practically the same IO. Then you get a Bonus screen to boot for displaying status or maybe as a remote HMI as well as bonus comm ports. The fact that the EX_RC1 isn't battery backed might also sway that decision. Not certain why Emil is adamant about using a Unitronics made expansion cable. At the end of the day it is just shielded CAT5e. If you purchase good quality shielded connectors and know how to make an Ethernet cable this is about as easy as it gets. You just have to make sure and maintain the correct twisted pair relationship and extend the shield wire out for termination at one end. I always make my own expansion cables just so that I can make them exact length. I have never had an issue with a hoe grown cable. D

Food for thought, You could get another small Uni with CAN and go UniCan between that and the V1040. then use a short expansion cable to you remote I/O, or, if there is enough, jsut use the I/O on the Uni. In this way you could use the Uni as a passthtough with the fringe benefit of having a remote HMI. D

I agree with Ziwi. This is a huge undertaking and I'm not sure the UNI is suited for that type of control. I use fanuc robots, and everything is well documented. However, the don't make the documentation very accessible to just anyone. I am on their integrator program and it is still like pulling teeth to get some information. D

Hi Jenkins, I do believe still that you raise a good point regarding a word and byte swap on the data values. I have been really fortunate when communicating with the Unitronics that the device i was communicating with had the word swap features built in when they have been needed. I have yet to see anything that requires a btye swap as well, but I did read theat they exist. But at least the word swap on the data value is pretty common and should be built in to the Uni somehow. D

Jenkins, Your welcome. Glad to hear you were at least able to get the VFD to communicate. For some reason I was unable to open the file you posted. It says it is corrupt. D

Just an observation ................. Moderation seems to have crawled to a halt recently. We've had instances recently where it has taken multiple days to get a message through. Often times by the time you respond, several other have as well and the info in your post may be obsolete before it even makes it online. Another forum I use a lot, PLCS.net, are able to post your comments almost immediately (probably because it is mostly automated). I do understand why we have moderation, but the current pace of things detracts heavily from the value. So my question is, if other forums such as PLCs.net can do it, why can't this one. There are others on this forum I have seen on that forum and they could probably attest to the fact that it is very fast, and I to this point have not seen where any form of abuse has leaked through with them either. D

Hi Jenkins, There is more. If you are looking to read 40009 in the drive, you need to subtract 40001 from you parameter number. Therefore, the number you need to put in as your target address is actually (40009-40001) = 8. This is considered the "offset". The 40000 part is implicitly understood in this case by way of the function call you are using. So the actual stream you send to the "inverter control input" parameter of the drive should look like this. 65 06 00 08 00 00 XX YY where XX and YY are whatever the checksum ends up being. From page 206 in the FR-D700 manual. Please try this and let me know how you make out. Also, I made a post yesterday that still hasn't made it through moderation yet. So it will be a bit behind the times. I hope this goes through at least at the same time. D

Hi Jenkins, In order for me to duplicate your output buffer i had to use a modbus offset of 37705. Looking at my FR-D700 manual, they do not list any offsets above 4000. At least in this specific instance, it is very likely that you aren't getting a response because you are trying to write to an unavailable memory area. My transmit buffer is as follows 65 06 93 49 00 00 7D 7C I'm also not susre why you were getting a CRC of 7E 68 as on my V570 it shows it as 7D 7C. D

Hi Jenkins, To what address are you trying to write to in the VFD? Based on your data field above, you are using a function code 06 to write a value of 0 to address 37,705. This address value does not appear to be in range of any holding registers in the VFD. When you are entering a value into the slave operand address, are you entering it as a HEX or a DEC value? What value is it? The address value 9349 doesn't seem right. D

Hi Jenkins, I did some more looking and can't find one single instance of a manufacturer using a byte swap on the CRC. The confusion seems to be with the modbus documentation itself. Apparently the algrithm for generating the CRC already effectively performs the byte swap during the processing. As a result, the calculated low byte of the CRC is stored in the High byte, and the calculated high byte of the CRC is stored in the low byte. I have done modbus to Mitsubishi drives in the past, and everything worked fine. Have you actually attempted to try the communication "as is" between the Uni and the FR VFD? You'll probably find it actually does work and that it is just a matter of some very poor documentation that is at best very confusing and misleading. this is a link to a discussion I found that covers it. http://modbus.control.com/thread/1026168695 D

Hi Fabios, You can find them here. They are meant to be a means for you to measure the speed of execution of your code. It is basically the start and stop for a very high resolution timer. D

I've done a ton of modbus over the years, and I have never seen a byte swap on the CRC. Maybe I've just been really lucky. If they did this, they are making it virtually incompatible with every other modbus device out there I would think. Byte swap on the data value is pretty common. Is it possible you mean this instead?